Service section

The Service element defines a group of configuration settings for service attributes. Multiple service elements can be defined in this section with different configuration settings for each service. Defining multiple services allows you to use more than one service within a single application. You can add or update (or remove) a service to an existing application dynamically using PMC.

name

Name of the service to run for this application. The service name must be unique within the application.

A client application can use the appropriate API to override the service that is used to execute workload. Refer to the API Reference for more details. The service name that the client specifies must be configured in the application profile.

Where used

Service

Required/Optional

Required

Valid values

1—256 alphanumeric characters, including all printable characters.

Related attributes

  • serviceName—Name of service that is used to execute the workload for the sessions in this session type.

description

String that describes the service.

Where used

Service

Required/Optional

Optional

Valid values

1—256 alphanumeric characters, including all printable characters.

default

Identifies a service as the default service, which means that the default service is immediately started when the service instance manager starts.

Where used

Service

Required/Optional

Optional when one service section is defined.

Required when multiple service sections are defined.

Valid values

true | false

Default value

True if only one service is defined in the application profile. If only one service is defined, that service is identified as the default and is started when the service instance manager starts.

When multiple services are defined, at least one of the services default value should be set to true. Other services' default value are optional.

packageName

Name assigned to the service package during deployment. The value you specify here must match the value specified during deployment.

Where used

Service

Required/Optional

Required if you use the SOAM_DEPLOY_DIR variable in the Service section; optional if you do not use that variable in the Service section.

Default

None

maxOtherInstances

Applies only when multiple services are used in a single application. Defines the maximum number of other service instances that a single service instance manger can run concurrently, in addition to the current service.

When this parameter is set to 0, no other service instances started by the service instance manager can run at the same time when this service instance manager starts this service. As a result, any other running service instances managed by this service instance manager are stopped when this service is started.

When this parameter is set to a number larger than 0, the service instance manager can keep maxOtherInstances service instances running along with this service concurrently. Setting a value larger than 0 saves service instance loading time, because service instances are not shut down and restarted.

When a service instance manager needs to shutdown a service to satisfy maxOtherInstances, it first tries to gracefully shutdown the service instance. If the service instance does not exit when the DestroyService timeout (Service > Control > Method > Timeout, duration attribute) expires, the process is killed.

Where used

Service

Required/Optional

Optional

Default

0, only one service instance can run at a time.

Example

For example, if you have three services with different values for maxOtherInstances:


Name

maxOtherInstances

Default

S1

1

true

S2

1

false

S3

0

false


When the service instance manager starts, it starts service S1 by default. The service instance manager has one child process (S1). When service S2 is started, the service instance manager has 2 child processes (S1 and S2). If service S3 is started, the service instance manager has only one child process, which is S3 (S1 and S2 are shutdown by the service instance manager).

When service S1 is started again, the service instance manager has only one child process, which is S1 (S3 is shutdown by the service instance manager because it’s maxOtherInstances is 0).

deploymentTimeout

Maximum time, in seconds, to wait before soamdeploy checks the connection with the repository server.

Where used

Service

Required/Optional

Optional

Default

300 seconds

Valid values

0—2147483647

deploymentRetryCount

Specifies the number of times soamdeploy retries to connect to the repository server and download the service package from the repository server. After the service experiences the specified number of retries, the service is aborted.

Where used

Service

Required/Optional

Optional

Default

3

Valid values

0 or Positive integer.

debugSetting

Helps you to use a debugger to step through the service code and find any errors in the service logic or in the environment.

For the customized debugSetting, you can configure the specific events that you want Symphony to detect by specifying the customizedDebugAction for each of these events.

Where used

Service

Required/Optional

Optional

Default

none

Valid values

none | customized | full

none—never generates debug logs

customized—generates debug logs upon detection of specific customizable events

full—always generate debug logs

cleanupTimeout

Maximum time, in seconds, to allow a service instance to cleanup if an application is disabled or unregistered, ora middleware component becomes unavailable.

Cleanup allows the running service method to gracefully finish executing. If the service method and cleanup does not complete within the set time, then Symphony will terminate the instance.

Where used

Service

Required/Optional

Optional

Default

60 seconds

Valid values

Positive integer

Service >osTypes >osType

Configuration related to the operating system in which services run.

name

Operating system environment in which to run the service. Symphony uses this information to determine where the executable for the service is located and set up the environment variables for the service instance.

Symphony supports:
  • all—This configuration is applied if the osType for the allocated resource is not configured in the application profile.

  • LINUX86—A 32-bit Linux-based environment, such as RedHat Linux

  • NTX86—A 32-bit Windows-based environment, such as Windows 2000, Windows NT, and Windows XP

  • X86_64—A 64-bit Linux-based environment

  • NTX64—A 64-bit Windows-based environment

  • SOL64—A Solaris SPARC based environment

  • SOLX8664—A Solaris x86-64 based environment

  • User-defined operating-system types, defined in the ego.shared file

Note:

While specifying PATH, ensure that you use the proper path delimiter (colon or semi-colon) according to the osType.

Where used

  • Service > osTypes > osType

Required/Optional

Required

Valid values

all | LINUX86 | X86_64 | NTX86 | NTX64 | SOL64 | SOLX8664

logDirectory

Used for log retrieval through the Platform Management Console. Path to the directory in which logs are written by services for this application. The path can be any desired path and must be the same on all compute hosts.

Configure logDirectory, fileNamePattern, and subDirectoryPattern for each operating system type defined in your service section.

Note:

Log retrieval is only available in Symphony on the grid. Log retrieval is not available in Symphony DE.

Where used

Service > OsTypes > osType

Required/Optional

Optional

Default value

  • Linux—$SOAM_HOME/work

  • Windows—%SOAM_HOME%\work

Related attributes

  • fileNamePattern—File naming convention for service log files written to the logDirectory.

  • subDirectoryPattern—Convention for naming subdirectories in the logDirectory.

fileNamePattern

Used for log retrieval through the Platform Management Console. File naming convention for service log files written to the logDirectory. Specify how your files are named. When retrieving logs for a specific task, the system looks for log files that partially match the file name pattern. If you are going to name files with the task ID or session ID, specify the variables %taskId% or %sessionId%.

Configure logDirectory, fileNamePattern, and subDirectoryPattern for each operating system type defined in your service section.

Note:

Log retrieval is only available in Symphony on the grid. Log retrieval is not available in Symphony DE.

Where used

Service > OsTypes > osType

Required/Optional

Optional

Valid values

alphanumeric string

Special variables: %taskId%, %sessionId%

Default value

empty, log retrieval is not enabled

Example

If log files have, for example, the service name, then sessionID, and task ID, for example, your log file name is sampleService_123_1.log, you can specify:

sampleService_%sessionId%_%taskId%.log

The system matches files containing the session ID and task ID.

Related attributes

  • logDirectory—Path to the directory in which logs are written by services for this application.

  • subDirectoryPattern—Convention for naming subdirectories in the logDirectory.

subDirectoryPattern

Used for log retrieval through the Platform Management Console. Convention for naming subdirectories in the logDirectory. If you want to name subdirectories according to session ID or task ID use the variables %sessionId%, %taskId%. When retrieving logs, the system looks for log files in subdirectories that partially match the sub-directory pattern.

Configure logDirectory, fileNamePattern, and subDirectoryPattern for each operating system type defined in your service section.

Note:

Log retrieval is only available in Symphony on the grid. Log retrieval is not available in Symphony DE.

Where used

Service > OsTypes > osType

Required/Optional

Optional

Valid values

alphanumeric string

Special variables: %sessionId%, %taskId%

Default value

empty, no subdirectories exist

Example

If you want to name subdirectories according to session ID, specify, without any backslashes:

%sessionId%

The system looks for logs in subdirectories named according to the session ID.

Related attributes

  • logDirectory—Path to the directory in which logs are written by services for this application.

  • fileNamePattern—File naming convention for service log files written to the logDirectory.

startCmd

Path to the program executable for the service. If you deploy a service package using Symphony deployment, the directory where your service package is extracted can be referred to as ${SOAM_DEPLOY_DIR}. If you need to reference a file in your service package, use the ${SOAM_DEPLOY_DIR} variable.

For example, on Windows, if in your service package you have the directory structure \myservice\myservice.exe, indicate ${SOAM_DEPLOY_DIR}\myservice\myservice.exe in startCmd.

For example, on Linux, if in your service package you have the directory structure /myservice/myservice, indicate ${SOAM_DEPLOY_DIR}/myservice/myservice. in startCmd.

Note:

To run a Windows .bat script, you need to specify a special syntax to run the batch file in command shell. For example:

<osType name=NTX86" startCmd="cmd /c cmd /c install.bat"/>

Where used

Service > osTypes > osType

Required/Optional

Required

Valid values

Any location accessible on your network or local disk.

workDir

Working directory of the service instance.

Where used

  • Service> osTypes > osType

Required/Optional

Optional

Valid values

Any location on local disk.

Default value

The default working directory for the service is:

  • ${SOAM_HOME}/work

preExecCmd

When using a deployment tool other than Symphony soamdeploy, the command specified here will run on the compute host and can be used to copy the service program to that host.

Multiple commands can be run by calling a script or batch file containing the commands. The path to this command must be defined by an environment variable.

preExecCmd is called only when the packageName is not configured in the service section.

Where used

Service > osTypes > osType

Required/Optional

Optional

Default value

"" (empty)—No pre-execution command will be executed

Service > osTypes >osType > env

Configure envirionment variables for running service instances.

name

Name of an environment variable to set in the runtime environment of the service. You can also define environment variables so that they get substituted in the startCmd, preExecCmd, and workDir attributes.

One env statement is required for each environment variable.

No environment variables need to be set for the service.

You can refer to defined environment variables in other environment variables. For example:

<env name="ENVAR1">${SOAM_HOME}/work</env>

<env name="ENVAR2">${ENVAR1}/${VERSION_NUM }</env>

Symphony substitutes the following environment variables with system values:

  • ${PATH}—Specifies the path to the relevant executable. The specified path is pre-pended in front of the system Path at runtime. For Windows, specifies the path to any dependent library, including the Symphony libraries.

  • ${LD_LIBRARY_PATH}—Linux only. Specifies the path to the library where the GCC-specific Symphony files are located. The specified path is pre-pended in front of the system LD_LIBRARY_PATH at runtime

  • ${SOAM_HOME}—Directory where Symphony is installed. Replaced with the value of the operating system environment variable SOAM_HOME set on the host.

  • ${VERSION_NUM}—Symphony version on which the service is running.

  • ${EGO_MACHINE_TYPE}—Specifies the host type installation. For example, win32-vc7 specifies a Windows machine. The variable is replaced with the value of the operating system environment variable EGO_MACHINE_TYPE set on the host.

  • ${SOAM_DEPLOY_DIR}—Internal system directory in which the service package is deployed.

  • ${SOAM_SERVICE_EVENT_REPLAY_LOG}— Service is driven by the events logged in the SERL file that this variable references. If this environment variable is not defined, service is driven by the SIM (as through Symphony).

    Note:

    EGO_MACHINE_TYPE, SOAM_DEPLOY_DIR, and SOAM_SERVICE_EVENT_REPLAY_LOG environment variables are reserved by Symphony, modification of these environment variables may result in undesirable behavior of your application.

Where used

  • Service > osTypes > osType > env

Required/Optional

Required

<Service ><Control><Method> element

name

Service API method to which defined events apply.

Where used

Service > Control > Method

Required/Optional

Required

Valid values

  • Register

  • CreateService

  • SessionEnter

  • SessionUpdate

  • Invoke

  • SessionLeave

  • DestroyService

Default value

No default value

<Service ><Control><Method><Timeout> element

Defines how long to wait for the method specified in <Method name=...> element to complete, and what action to take on service instances, sessions, or tasks, upon timeout of the method.

duration

Number of seconds to wait for the method specified in <Method name=...>to complete before a timeout is considered.

Required/Optional

Required

Valid values


Method

Valid value

Register

1 or more

CreateService

0 or more

SessionEnter

0 or more

SessionUpdate

0 or more

Invoke

0 or more

SessionLeave

0 or more

DestroyService

0 or more


Note:

The method never times out if you set the value to 0.

Default values


Method

Default value

Register

60 seconds

CreateService

0 seconds, never timeout

SessionEnter

0 seconds, never timeout

SessionUpdate

0 seconds, never timeout

Invoke

0 seconds, never timeout

SessionLeave

0 seconds, never timeout

DestroyService

15 seconds


actionOnSI

Action to take on the service instance when a timeout occurs.

Where used

Service > Control > Timeout

Required/Optional

Required

Valid values

  • blockHost—When a timeout is reached on the method, terminate the running service instance on this host and do not use this host to start any other service instance for the application. The host on which the service instance was running is added to the blocked host list for the application. This host is no longer selected to run work for the application until it is explicitly unblocked through the EGO command line or the Platform Management Console.

  • restartService—When a timeout is reached on the method, terminate the service instance, start a new service instance on the same host, and recover state. There is no limit to the number of times that a service instance can be restarted.

Not all values are possible with all methods. The table below outlines possible values:


Method

Possible action

Register

  • blockHost

  • restartService

CreateService

  • blockHost

  • restartService

SessionEnter

  • blockHost

  • restartService

SessionUpdate

  • blockHost

  • restartService

Invoke

  • blockHost

  • restartService

SessionLeave

  • blockHost

  • restartService

DestroyService

  • No action possible on the service instance


Default values

Default values differ according to method. The following table outlines default values by method.


Method

Default action

Register

  • blockHost

CreateService

  • blockHost

SessionEnter

  • blockHost

SessionUpdate

  • blockHost

Invoke

  • restartService

SessionLeave

  • restartService

DestroyService

  • No action possible


actionOnWorkload

Action to take on sessions and tasks when a timeout occurs.

Where used

Service > Control > Method > Timeout

Required/Optional

Required

Valid values

  • retry—When a timeout is reached on the method, retry the method up to the number of times configured by the session and task retry limits in the application profile.

    For SessionEnter and SessionUpdate, the system attempts to bind the session to the service instance up to the sessionRetryLimit in the application profile before the session is aborted.

    Note:

    The retry count for both of these methods are considered together. For example, if SessionEnter fails once and SessionUpdate fails twice, then the session rerun count is equal to 3. Therefore the SessionRetryCount should be set to a value that accounts for both SessionEnter and SessionUpdate failures.

    For Invoke, the system attempts to run the task up to the taskRetryLimit defined in the application profile before the task is failed.

  • fail—When a timeout is reached on the method, abort the session or fail the task, and propagate errors to the client application.

    For SessionEnter or SessionUpdate, immediately abort the session. Do not retry the method.

    For Invoke, immediately fail the task. Do not retry the method.

Not all values are possible with all methods. The table below outlines possible actions for methods:


Method

Possible action

Register

  • No action possible

CreateService

  • No action possible

SessionEnter

  • retry

  • fail

SessionUpdate

  • retry

  • fail

Invoke

  • retry

  • fail

SessionLeave

  • No action possible

DestroyService

  • No action possible


Default values

Default values differ according to method. The following table outlines default values by method for actions taken.


Method

Default action

Register

  • No action possible

CreateService

  • No action possible

SessionEnter

  • retry

SessionUpdate

  • retry

Invoke

  • retry

SessionLeave

  • No action possible

DestroyService

  • No action possible


customizedDebugAction

Action to take on sessions and tasks when a timeout occurs and service debugsettion="customized".

Where used

Service > Control > Method > Timeout

Required/Optional

Optional

Valid values

  • writeServiceEventReplayFiles—When Symphony detects that the specified method has timed out, it generates service event replay files to capture the relevant events that lead up to the timeout. This is the recommended setting if method timeout is an unexpected event for your service.

  • none—When Symphony detects that the specified method has timed out, it does not generate service event replay files. This is the recommended setting if your service times out as a normal occurrence.

Default value

writeServiceEventReplayFiles

<Service ><Control><Method><Exit> element

Defines what action to take on service instances, sessions, or tasks when the method specified with the <Method> element exits.

actionOnSI

Action to take on the service instance when the method exits.

Where used

Service > Control > Method > Exit

Required/Optional

Required

Valid values

  • blockHost—When the method exits, terminate the running service instance on this host and do not use this host to start any other service instance for the application. The host on which the service instance was running is added to the blocked host list for the application. This host is no longer selected to run work for the application until it is explicitly unblocked through the EGO command line or the Platform Management Console.

  • restartService—When the method exits, terminate the service instance, start a new service instance on the same host, and recover state. There is no limit to the number of times that a service instance can be restarted.

Note:

For DestroyService, there is no action is possible on the service instance.

Default values

Default values differ according to method. The following table outlines default values by method for actions.


Method

Default action

Register

  • blockHost

CreateService

  • blockHost

SessionEnter

  • blockHost

SessionUpdate

  • blockHost

Invoke

  • restartService

SessionLeave

  • restartService

DestroyService

  • No action possible


actionOnWorkload

Action to take on sessions and tasks when the method exits.

Where used

Service > Control > Method > Exit

Required/Optional

Required

Valid values

  • retry—If the service exits during execution of the specified method, retry the method up to the number of times configured by the session and task retry limits in the application profile.

    For SessionEnter and SessionUpdate, the system attempts to bind the session to the service instance up to the sessionRetryLimit in the application profile before the session is aborted.

    Note:

    The retry count for both of these methods are considered together. For example, if SessionEnter fails once and SessionUpdate fails twice, then the session rerun count is equal to 3. Therefore the SessionRetryCount should be set to a value that accounts for both SessionEnter and SessionUpdate failures.

    For Invoke, the system attempts to run the task up to the taskRetryLimit defined in the application profile before the task is failed.

  • fail—When the method exits, abort the session or fail the task, and propagate errors to the client application.

    For SessionEnter or SessionUpdate, immediately abort the session. Do not retry the method.

    For Invoke, immediately fail the task. Do not retry the method.

Not all values are possible with all methods. The table below outlines possible actions for methods:


Method

Possible action

Register

  • No action possible

CreateService

  • No action possible

SessionEnter

  • retry

  • fail

SessionUpdate

  • retry

  • fail

Invoke

  • retry

  • fail

SessionLeave

  • No action possible

DestroyService

  • No action possible


Default values

Default values differ according to method. The following table outlines default values by method for actions taken.


Method

Default action

Register

  • No action possible

CreateService

  • No action possible

SessionEnter

  • retry

SessionUpdate

  • retry

Invoke

  • retry

SessionLeave

  • No action possible

DestroyService

  • No action possible


customizedDebugAction

Action to take on sessions and tasks when the service process exits during the execution of the specified method and service debugSetting="customized"..

Where used

Service > Control > Method > Exit

Required/Optional

Optional

Valid values

  • writeServiceEventReplayFiles—When Symphony detects that the service process has exited (or crashed) while executing the specified method, it generates service event replay files to capture the relevant events that lead up to the exit. This is the recommended setting if the service process exiting or crashing in the specified method is an unexpected event for your service.

  • none—When Symphony detects that the service process has exited (or crashed) during execution of the specified method, it does not generate service event replay files. This is the recommended setting if your service exits as a normal occurrence.

Default value

writeServiceEventReplayFiles

<Service ><Control><Method><Return> element

Defines what action to take on service instances, sessions, or tasks when the method specified in <Method name=...> returns normally (controlCode=0), or if a control code is defined, what action to take when the method returns with the specified control code.

actionOnSI

Action to take on the service instance when the method returns normally or with the specified control code.

Where used

Service > Control > Method > Return

Required/Optional

Required

Valid values

Note:

Actions on return cannot be configured for Register or DestroyService

  • blockHost—When the method returns normally or with a specified control code, terminate the running service instance on this host and do not use this host to start any other service instance for the application.

    The host on which the service instance was running is added to the blocked host list for the application. This host is no longer selected to run work for the application until it is explicitly unblocked through the EGO command line or the Platform Management Console.

  • restartService—When the method returns normally or with a specified control code, terminate the service instance, start a new service instance on the same host, and recover state. There is no limit to the number of times that a service instance can be restarted.

  • keepAlive—When the method returns normally or with a specified control code, take no action on the running service instance. Return an error only.

Default values


Method

Default value

Register

  • No action possible

CreateService

  • keepAlive

SessionEnter

  • keepAlive

SessionUpdate

  • keepAlive

Invoke

  • keepAlive

SessionLeave

  • keepAlive

DestroyService

  • No action possible


controlCode

Numeric identifier that indicates to the system what action to take based on the number that is returned by the method specified in the <Method> element. There can be multiple control codes defined per method, and different actions to take based on control code.

Where used

Service > Control > Method > Return

Required/Optional

Required

Valid values

integers, positive and negative

Default value

0, default action taken on workload and service instances, as specified by default actions on actionOnSI and actionOnWorkload.

actionOnWorkload

Action to take on sessions and tasks when the method returns normally, or with a specified control code.

Where used

Service > Control > Method > Return

Required/Optional

Required

Valid values

  • retry—When the method returns normally or with the specified control code, retry the method up to the number of times configured by the session and task retry limits in the application profile.

    For SessionEnter and SessionUpdate, the system attempts to bind the session to the service instance up to the sessionRetryLimit in the application profile before the session is aborted.

    Note:

    The retry count for both of these methods are considered together. For example, if SessionEnter fails once and SessionUpdate fails twice, then the session rerun count is equal to 3. Therefore the SessionRetryCount should be set to a value that accounts for both SessionEnter and SessionUpdate failures.

    For Invoke, the system attempts to run the task up to the taskRetryLimit defined in the application profile before the task is failed.

  • fail—When the method returns normally or with the specified control code, abort the session or fail the task, and propagate errors to the client application.

    For SessionEnter or SessionUpdate, immediately abort the session. Do not retry the method.

    For Invoke, immediately fail the task. Do not retry the method.

  • succeed—This is a normal return. This is treated as a successful execution of SessionEnter, SessionUpdate, or Invoke.

    For Invoke, the taskcompletes successfully (in the Done state).

Not all values are possible with all methods. The table below outlines possible actions for methods:


Method

Possible value

Register

  • No action possible

CreateService

  • No action possible

SessionEnter

  • retry

  • fail

  • succeed

SessionUpdate

  • retry

  • fail

  • succeed

Invoke

  • retry

  • fail

  • succeed

SessionLeave

  • No action possible

DestroyService

  • No action possible


Default values

Default values differ according to method.


Method

Default value

Register

  • No action possible

CreateService

  • No action possible

SessionEnter

  • succeed

SessionUpdate

  • succeed

Invoke

  • succeed

SessionLeave

  • No action possible

DestroyService

  • No action possible


customizedDebugAction

Action to take on the service instance when the method returns normally or with the specified control code when service debugSetting="customized".

Where used

Service > Control > Method > Return

Required/Optional

Optional

Valid values

  • writeServiceEventReplayFiles—When Symphony detects that the specified method has returned normally with or without a specific control code, it generates service event replay files.

  • none—When Symphony detects that the specified method has returned normally with or without a specific control code, it does not generate service event replay files. This is the recommended setting, as this is typically a normal, successful event.

Default value

none

<Service ><Control><Method><Exception> element

Defines what action to take on service instances, sessions, or tasks when the method specified in <Method name=...> encounters a fatal or failure exception.

type

Exception type to which the configured action applies. Exception types cannot be configured for Register or DestroyService.

Where used

Service > Control > Method > Exception

Required/Optional

Required

Valid values

  • failure— Exception type is FailureException.

  • fatal— Exception type is FatalException.

Default values

No default value

controlCode

Numeric identifier that indicates to the system what action to take based on the number that is returned by the specified exception. There can be multiple control codes defined per exception, and different actions to take based on control code.

Where used

Service > Control > Method > Exception

Required/Optional

Required

Valid values

integers, positive and negative

Default value

0, default action taken on workload and service instances, as specified by default actions on actionOnSI and actionOnWorkload.

actionOnSI

Action to take on the service instance when a failure or fatal exception occurs.

Where used

Service > Control > Method > Exception

Required/Optional

Required

Valid values

  • blockHost—When the specified exception occurs, terminate the running service instance on this host and do not use this host to start any other service instance for the application.

    The host on which the service instance was running is added to the blocked host list for the application. This host is no longer selected to run work for the application until it is explicitly unblocked through the EGO command line or the Platform Management Console.

  • restartService—When the specified exception occurs, terminate the service instance, start a new service instance on the same host, and recover state. There is no limit to the number of times that a service instance can be restarted.

  • keepAlive—When the specified exception occurs, take no action on the running service instance.

Note:

Actions cannot be configured for Register or DestroyService


Method

Possible values

Fatal Exception

Possible values

Failure Exception

Register

No action possible

No action possible

CreateService

  • blockHost

  • restartService

  • blockHost

  • restartService

SessionEnter

  • blockHost

  • restartService

  • keepAlive

  • blockHost

  • restartService

  • keepAlive

SessionUpdate

  • blockHost

  • restartService

  • keepAlive

  • blockHost

  • restartService

  • keepAlive

Invoke

  • blockHost

  • restartService

  • keepAlive

  • blockHost

  • restartService

  • keepAlive

SessionLeave

  • blockHost

  • restartService

  • keepAlive

  • blockHost

  • restartService

  • keepAlive

DestroyService

No action possible

No action possible


Default values


Method

Default values

Fatal Exception

Default values

Failure Exception

Register

No action possible

No action possible

CreateService

  • blockHost

  • blockHost

SessionEnter

  • keepAlive

  • keepAlive

SessionUpdate

  • keepAlive

  • keepAlive

Invoke

  • keepAlive

  • keepAlive

SessionLeave

  • keepAlive

  • keepAlive

DestroyService

No action possible

No action possible


actionOnWorkload

Action to take on sessions and tasks when a fatal or failure exception occurs.

Where used

Service > Control > Method > Exception

Required/Optional

Required

Valid values

  • retry—When the specified exception occurs, retry the method up to the number of times configured by the session and task retry limits in the application profile.

    For SessionEnter and SessionUpdate, the system attempts to bind the session to the service instance up to the sessionRetryLimit in the application profile before the session is aborted.

    Note:

    The retry count for both of these methods are considered together. For example, if SessionEnter fails once and SessionUpdate fails twice, then the session rerun count is equal to 3. Therefore the SessionRetryCount should be set to a value that accounts for both SessionEnter and SessionUpdate failures.

    For Invoke, the system attempts to run the task up to the taskRetryLimit defined in the application profile before the task is failed.

  • fail—When the specified exception occurs, abort the session or fail the task, and propagate errors to the client application.

    For SessionEnter or SessionUpdate, immediately abort the session. Do not retry the method.

    For Invoke, immediately fail the task. Do not retry the method.

Not all values are possible with all methods. The table below outlines possible actions for methods:


Method

Possible values

Fatal Exception

Possible values

Failure Exception

Register

No action possible

No action possible

CreateService

No action possible

No action possible

SessionEnter

  • retry

  • fail

  • retry

  • fail

SessionUpdate

  • retry

  • fail

  • retry

  • fail

Invoke

  • retry

  • fail

  • retry

  • fail

SessionLeave

No action possible

No action possible

DestroyService

No action possible

No action possible


Default values

Default values differ according to method.


Method

Default values

Fatal Exception

Default values

Failure Exception

Register

No action possible

No action possible

CreateService

No action possible

No action possible

SessionEnter

  • fail

  • retry

SessionUpdate

  • fail

  • retry

Invoke

  • fail

  • retry

SessionLeave

No action possible

No action possible

DestroyService

No action possible

No action possible


customizedDebugAction

Action to take on sessions and tasks when a fatal or failure exception occurs in the specified method and debugSetting="customized".

Where used

Service > Control > Method > Exception

Required/Optional

Optional

Valid values

  • writeServiceEventReplayFiles—When Symphony detects that the specified method has thrown a particular exception (FatalException or FailureException), as specified, it generates service event replay files to capture the relevant events that lead up to the exception.

  • none—When Symphony detects that the specified method has thrown a particular exception (FatalException or FailureException), as specified, it does not generate service event replay files.

Default value

writeServiceEventReplayFiles