Specifying Dispatcher Parameters

There are three generic process types that are the basis for all dispatcher processes:

PSBRKDSP, which is the publication broker dispatcher.
PSPUBDSP, which is the publication contractor dispatcher.
PSSUBDSP, which is the subscription contractor dispatcher.

The following parameters apply to all three process types.

Field or Control	Description
Recycle Count	Specifies the number of times each dispatcher process is executed before being terminated (intentionally) by the system and then immediately restarted. Note: In general, you should not recycle dispatchers and should set this property equal to 0 (zero). The Recycle Count parameter does not translate into a native Oracle Tuxedo parameter in the PSAPPSRV.UBB file. Instead, the value is stored in memory and is managed by the system.
Allowed Consec Service Failures (Allowed consecutive service failures)	This option enables dynamic server process restarts in the event of service failures. To set this option, enter a number greater than 0. To disable it, enter 0. The default value for this parameter is 2. The value that you enter is the number of consecutive service failures that cause a recycle of the server process. This is a catchall error handling routine that allows a dispatcher to terminate itself if it receives multiple, consecutive, fatal error messages from service routines. Such errors should not occur consecutively; however, if they do, it indicates that the server process needs to be recycled or cleansed. A retry message appears when the specified number of service failures occurs.
Dispatch List Multiplier	Limits the number of dispatched messages by the number you specify, multiplied by the number of associated handler(s). This parameter is useful for unordered queues when all messages could go out at once. The default value is 10.
Scan Interval	Specifies the number of seconds between scans of the work queue when idle. The default value is 15 seconds. The scan interval is necessary to detect the following types of messages: Messages published from an application server domain that is not the active pub/sub domain as selected on the Domain Status page in the Service Operations Monitor. Cases where the broker server does not receive a notice of the publication. When a message is in the queue, the broker server doesn’t receive a notice of the publication. A scan interval is required to make sure these types of messages are processed in a timely manner. The scan interval is analogous to the polling that PeopleSoft Process Scheduler performs on the Process Request table. In addition, the scan interval detects messages that have been resubmitted—for example, after an error. Decreasing the scan interval decreases latency for these types of publishes and error recovery. Note: The scan interval and ping rate (as a percentage) determines the actual interval for pinging any unavailable remote nodes. The algorithm used is: (attempts) x (ping rate) x (scan interval).
Ping Rate	Determines the number of seconds of inactivity before the server scans the database queues to restart any stalled or crashed items. The default value is 150 seconds. The ping rate is used in conjunction with the scan interval for pinging remote nodes. See the definition for Scan Interval in this section.
Maximum Ping Interval	Determines the maximum interval, in hours, between subsequent attempted pings of any unavailable remote nodes.
Dispatcher Queue Max Queue Size	Determines the maximum number of items per service operation queue that the dispatcher keeps in memory. The default value is 1000.
Memory Queue Refresh Rate	PeopleSoft Integration Broker maintains current asynchronous messaging queues in system memory for quick access. Occasionally, these cached queues can become corrupted. At that point, they must be refreshed from the PeopleSoft Integration Broker data tables. The likelihood and frequency of cache corruption depends on a combination of factors specific to the messaging system. If you need to periodically refresh the in-memory queues, you can use this parameter to tailor the frequency of the refresh to fit the situation. Each dispatcher on the system has its own queue. For each queue, you set the rate equal to the number of dispatch attempts that must occur before the queue is refreshed. The refresh occurs only when the specified number of dispatch attempts is reached for a given message queue. For example, with a memory queue refresh rate of 8, multiple queues could have up to seven dispatch attempts each without triggering any refresh. The following settings are also significant: A setting of 0 (the default) disables the refresh altogether. A setting of 1 triggers a refresh immediately after every dispatch attempt, effectively disabling memory caching.
Restart Period	Specifies the number of seconds between restart attempts on Started items in the work queue. An item which stays in Started state for more than a few seconds might be stalled—for example, the service request might have been lost, or the handler might have crashed. Decreasing the restart period reduces the latency for recovering stalled items with the status Started. However, under high load, items might stay in the Started state longer than normal for valid reasons. All handlers might be busy, and the handler service request for the item might be queued at the Oracle Tuxedo level. Setting the restart period too low results in redundant restarts. The dispatcher dispatches the item again, even though the original request is still in the Tuxedo queue. A small number of extra restarts is benign; however, at higher volumes, the unnecessary restarts can fill up the queue and block real requests. The formula for a reasonable value for the restart period is: ((incoming requests per second) / (number of handlers)) × (average processing time per request) For example, if you have an incoming rate of 20 per second, and you have four handlers, each handler is busy processing one item and will have four others waiting in the queue. A new item must wait for the currently processing item—plus the four items in the queue—before it is processed. If each item takes 10 seconds to process, the new item will stay in Started status for approximately 50 seconds before the handler works on it. If it stays in Started status longer, it's likely that the request to the handler has been lost, and the item should be restarted. Note: Using a value greater than 3540 for the dispatcher restart period results in constant restarts.