Configuring Messaging Servers

Specifies the number of times each dispatcher process is executed before being terminated (intentionally) by the system and then immediately restarted.

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.

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.

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.

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.

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.

Determines the maximum interval, in hours, between subsequent attempted pings of any unavailable remote nodes.

Determines the maximum number of items per service operation queue that the dispatcher keeps in memory. The default value is 1000.

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.

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:

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.

Specifies the number of handler server processes started at boot time.

Specifies the maximum number of handler server processes that can be started or spawned.

Specifies the number of seconds a handlers waits for a service request before timing out.

Service timeouts are recorded in the TUXLOG and APPSRV.LOG. In the event of a timeout, the handler terminates itself and Oracle Tuxedo automatically restarts the process.

Specifies the number of times that the system executes each server before the PeopleSoft system intentionally terminates the process.

Server processes must be intermittently recycled to clear buffer areas. The time required to recycle a server is negligible (a matter of milliseconds). 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 PeopleSoft system.

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 for this parameter is 2. The numerical 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 handler 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.

Specifies the maximum number of times that the server attempts to restart a failed action.

This parameter prevents a bad item from continuously crashing a handler process. The counter is incremented when the handler sets the status to Working but before it actually starts processing the item.

Disables the physical document cache.

In the development environment, set this property to 1 to disable cache.

In the production environment, set this property to 1 to disable cache.