Siebel Deployment Planning Guide > Siebel Architecture Overview >

About Siebel Connection Broker


The Siebel Connection Broker (SCBroker) server component provides intraserver load balancing. SCBroker distributes server requests across multiple Application Object Manager (AOM) 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 AOM process with the least number of running tasks, or forwards the request to another AOM process in round-robin fashion. A user session is created on this AOM. Thereafter, the requests that apply to this session are directly sent to the AOM 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, 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 AOM 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 AOM process with the fewest number of tasks.
    • The round-robin scheme routes each request to the next AOM process, cycling through all AOM processes.

      NOTE:  Support for the ConnForwardAlgorithm parameter requires Siebel Fix Pack version 8.0.0.9 or later.

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

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

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

        For detailed 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 AOM 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 new tasks would be routed to this unresponsive process. With the round-robin scheme, however, one request would be routed to this process for each "round" of requests routed to all participating AOM processes.

        Sometimes an individual connection request is not forwarded to an existing AOM process but instead causes a new AOM process to start. This can occur with either forwarding algorithm, when each existing AOM process has reached its theoretical maximum number of tasks, based on dividing the maximum number of tasks by the maximum number of AOM processes. A new process starts only if the maximum number of tasks and the maximum number of AOM 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 will wait for an AOM process to accept a request. The default is 500 milliseconds. This time-out minimizes wait time when SCBroker forwards a connection request to an AOM process, and the request cannot be accepted.

    If a time-out occurs, 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, the SWSE forwards the request to an AOM 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, the SWSE forwards the request to the load balancer. The load balancer forwards the request to an AOM 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 will wait for all 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, the request is sent back to the Web server in the same fashion as a connection forward time-out.

Siebel Deployment Planning Guide Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices.