Tuning Server Request Broker (SRBroker)

The Server Request Broker (SRBroker) component routes requests between Siebel Server components, such as from a Siebel Application Object Manager to a batch component. SRBroker also handles requests between batch components. SRBroker is used whether the components run on the same computer or on different computers.

Server requests originating with a Siebel Application Object Manager component always go to the SRBroker component to determine what to do with the request:

If the destination component is running on the same Siebel Server, then SRBroker passes the request to this component. If multiple instances of the destination component are running, then SRBroker passes the request to each component instance in a round-robin fashion.
If the destination component is not running on the same Siebel Server, then SRBroker passes the request to SRBroker running on another computer. If the destination component runs on multiple Siebel Servers, then SRBroker passes the request to each server in round-robin fashion.

The default parameter values for SRBroker work well for most deployments. If necessary, adjust the value of the MaxTasks parameter (the default value is 100). MaxTasks determines the maximum number of SRBroker threads (tasks) that can run on the Siebel Server. As necessary, set MaxTasks to a value equal to the number of batch components running on the Siebel Server, plus the number of Siebel Servers in the enterprise, plus 10 (for overhead).

MaxMTServers and MinMTServers determine the maximum and minimum number of SRBroker multithreaded processes that can run on the Siebel Server. Each multithreaded process can run a maximum of MaxTasks divided by MaxMTServers threads. Default values for MaxMTServers and MinMTServers must be set to 1. Increasing this value will not increase performance, and will not have any benefit.

Caution: Setting MaxTasks parameter values for SRBroker components in such a way that does not meet these guidelines might result in request failures.

For more information about the SRBroker and SRProc components, see Siebel System Administration Guide.

Addressing Siebel Server Request Broker Hang Issue

Applies to: Siebel 16.10 and above, including IP2017 and above

In certain scenarios, Siebel Service Request Broker (SRBroker) may experience hanging issues due to actions like clearing LOV cache or RTE reload. Oracle provides a recommended approach to mitigate these SRBroker hang problems.

Setting SIEBEL_SRB_SEND_RESP_TIMEOUT Environment Variable: To prevent SRBroker from hanging, it is advised to configure the SIEBEL_SRB_SEND_RESP_TIMEOUT environment variable. This configuration is particularly effective in addressing network connection issues that lead to hanging. Follow these steps:

Edit the siebenv.sh shell script to set the SIEBEL_SRB_SEND_RESP_TIMEOUT parameter to 5 seconds.
Ensure this configuration change is applied to all Siebel Servers running the SRBroker component within the enterprise.

Note: The SIEBEL_SRB_SEND_RESP_TIMEOUT parameter enforces a timeout for network connections that fail to receive a timely response. In case of a timeout detection on a network connection for the Response Thread, an appropriate log entry is generated.
The log file will be periodically updated based on the interval specified by the SIEBEL_SRB_SEND_RESP_TIMEOUT parameter.
Upon encountering a timeout, it is essential to investigate the specific component that is unresponsive to the Response Thread.
Adjust the SIEBEL_SRB_SEND_RESP_TIMEOUT parameter according to log analysis and observed performance to ensure optimal settings.

By configuring the SIEBEL_SRB_SEND_RESP_TIMEOUT environment variable as described above, organizations can effectively address SRBroker hanging issues caused by unresponsive components or network connection timeouts.

For more detailed information and guidance, please refer to Oracle's official documentation and support resources.