Siebel Deployment Planning Guide > Siebel Architecture Overview >

About the Siebel Connection Broker

The Siebel Connection Broker (SCBroker) server component provides intraserver load balancing. SCBroker distributes server requests across multiple Application Object Manager processes running on a Siebel Server.

SCBroker listens on a configurable, static port for new requests. When a new request is received, it forwards the request to the Application Object Manager process with the least number of running tasks, or forwards the request to another Application Object Manager process in round-robin fashion. A user session is created on this Application Object Manager. Thereafter, the requests that apply to this session are directly sent to the Application Object Manager process hosting the session.

SCBroker is enabled by default and has several parameters:

• PortNumber. Sets the port number on which SCBroker listens. The default is 2321, but you can change the port number.
• DfltTasks. Sets the default number of processes for SCBroker. The recommended value is 2.
• MaxTasks. Sets the maximum number of processes for SCBroker. The recommended value is 2. This value cannot be less than DfltTasks.
• AutoRestart. Default is On. If SCBroker terminates abnormally, then this setting allows it to restart automatically. Setting this parameter to Off or False is not recommended.
• ConnForwardAlgorithm. The connection forwarding algorithm is the routing scheme for SCBroker to use when routing intraserver requests to Application Object Manager processes. Possible values are LL (least-loaded) and RR (round-robin). SCBroker uses the least-loaded algorithm by default.
  • The least-loaded scheme routes each request to the Application Object Manager process with the fewest number of tasks.
  • The round-robin scheme routes each request to the next Application Object Manager process, cycling through all of the Application Object Manager processes.

    The round-robin algorithm does not take the number of running tasks for each Application Object Manager process into account. It simply forwards each request to the next Application Object Manager process among the available processes. The least-loaded algorithm considers only the current number of tasks for each Application Object Manager process that is running.

    In many circumstances, how an individual connection request is forwarded might be the same for either forwarding algorithm. The actual forwarding behavior depends on these factors:

  • The current number of Application Object Manager processes.
  • The current number of tasks for the Application Object Manager component and for each Application Object Manager process.
  • Patterns of requests for new tasks and patterns of threads being freed up through logouts.
  • Application Object Manager parameter settings controlling the maximum number of tasks and the minimum and maximum number of Application Object Manager processes. The applicable parameters are:
    • Maximum Tasks (MaxTasks)
    • Minimum MT Servers (MinMTServers)
    • Maximum MT Servers (MaxMTServers)

      For information about calculating the settings for MaxTasks, MaxMTServers and MinMTServers, see Siebel Performance Tuning Guide.

      NOTE:  Using the round-robin routing scheme instead of the least-loaded scheme can enhance availability in some cases where multiple Application Object Manager processes are running and one process is nonresponsive. Eventually, the nonresponsive process will have the least number of tasks. With the least-loaded scheme, all of the new tasks are routed to this unresponsive process. With the round-robin scheme, however, one request is routed to this process for each round of requests that is routed to all of the participating Application Object Manager processes.

      Sometimes an individual connection request is not forwarded to an existing Application Object Manager process but instead causes a new Application Object Manager process to start. This can occur with either forwarding algorithm, when each existing Application Object Manager process has reached its theoretical maximum number of tasks, based on dividing the maximum number of tasks by the maximum number of Application Object Manager processes. A new process starts only if the maximum number of tasks and the maximum number of Application Object Manager processes have not yet been reached.

      For more information about applicable parameters, see also Siebel System Administration Guide and Siebel Performance Tuning Guide.

• ConnForwardTimeout. The connection forward time-out determines how long SCBroker waits for an Application Object Manager process to accept a request. The default is 500 milliseconds. This time-out minimizes wait time when SCBroker forwards a connection request to an Application Object Manager process, and the request cannot be accepted.

  If a time-out occurs, then SCBroker reports an error back to the Web server. The SWSE then modifies the request by appending RR to the Siebel application URL. The SWSE then retries the request.

  • If you are using Siebel native load balancing, then the SWSE forwards the request to an Application Object Manager process on another Siebel Server. The Siebel Server is selected using a round-robin algorithm.
  • If you are using a third-party HTTP load balancer, then the SWSE forwards the request to the load balancer. The load balancer forwards the request to an Application Object Manager process on another Siebel Server. The Siebel Server is selected using a round-robin algorithm.
• ConnRequestTimeout. The connection request time-out determines how long SCBroker waits for all of the packets in an incoming new request. The default is 500 milliseconds. This time-out minimizes SCBroker wait time when TCP/IP requests are incomplete.

  If a time-out occurs, then the request is sent back to the Web server in the same fashion as a connection forward time-out.