Releasing inactive session managers

An IBM® Spectrum Symphony Session Manager (SSM) can be configured to shut itself down if it is inactive for a specified amount of time.

Normally, an SSM does not shut down after it is created, even when the workload is done for the session. Inactive SSMs continue to occupy system resources and can cause inefficient use of system resources if the number of inactive SSMs increases on a large scale. An inactive SSM is defined as having:
  • No active session
  • No client connection
  • No active history data writing

If new connections come from any client, the SSM resets the inactivity timer. When the duration of SSM inactivity exceeds the configured inactivity timeout, the SSM notifies the SD to not restart the SSM and releases the existing allocation. The SSM then shuts itself down gracefully. The reason it is necessary for the SSM to notify SD before shutting down is because SD will restart the SSM if it detects the connection to the SSM is broken.

Feature interactions

If the SSM inactivity timeout feature is configured, it can have an effect on other IBM Spectrum Symphony features.

Local standby

The SSM is considered active and does not shut itself down if there are local standby services. The SSM will shut down due to the inactive state if there is no local standby service even if the local standby feature is enabled.

Global standby

With the global standby feature, the SIM and services remain active for global future workload. When the inactive SSM requests to shut itself down, the SIM and services remain without occupying any slots. So when new workload comes, a new SSM is started and detects the standby SIM and services, instead of creating a new SIM and services. An application with global standby services can be inactive if the criteria for inactivity is met.

Multi-SSM

The SSM inactivity timeout feature is effective for the whole logical application. When the idle state of any of these SSMs reaches the inactivity timeout, the SSM notifies the SD and then shuts down only itself, and not all the SSMs for the logical application. The primary SSM shuts down first due to its own inactive timeout. However, when the client submits a session, it builds a connection with all the child SSMs. All of the child SSMs keep active until the session is finished. So all the child SSMs shut down almost at the same time due to the same inactivity if all of them can finish the history data without delay.

Prestart application

The SSM is considered active and does not shut itself down if the prestart application feature is enabled. An INFO message is logged when SSM initializes if the inactivity timeout is set and prestart application is enabled.

DelaySlotRelease

The DelaySlotRelease time is ignored and an INFO message is given if the SSM inactivity timeout is set and the feature DelaySlotRelease is enabled. It is assumed that the SSM inactivity timeout overrides all other settings. The SSM will release all the existing allocations, including those allocations with delaySlotRelease to EGO.

Dynamic application update

The configuration of SSM_INACTIVE_TIMEOUT in the SD service profile and inactiveTimeout in the application profile cannot be dynamically updated. If SSM_INACTIVE_TIMEOUT is updated in the SD service profile, it does not take effect until both the SD and SSM are restarted. If inactiveTimeout is updated in the application profile, it does take effect until the SSM is restarted.

Configuring SSM inactivity timeout

There are two parameters for configuring the inactivity timeout:
  • SSM_INACTIVE_TIMEOUT: Inactivity timeout for all SSMs in the cluster. This is a cluster-wide setting.
  • inactiveTimeout: Inactivity timeout for a specific SSM. This setting is for a single application.

The parameter SSM_INACTIVE_TIMEOUT is configured in the SD service profile from the cluster management console or CLI. After configuring this parameter, the timeout takes effect after restarting the SD and SSM.

The parameter inactiveTimeout is configured in the application profile from CLI and should be a positive integer. After configuring this parameter, the timeout takes effect after restarting the SSM.

If SSM_INACTIVE_TIMEOUT and inactiveTimeout are both configured, the application-level parameter inactiveTimeout overrides the cluster-level parameter SSM_INACTIVE_TIMEOUT.