Messaging Server (Pub/Sub) settings

This document is designed to specifically explain configuration parameters for the Peoplesoft Messaging Server (aka PUB/SUB)
This document is intended for technical users, installers, system administrators, and programmers who implement, maintain, or develop integration points for your PeopleSoft system. To take full advantage of the information covered in this document, we recommend that you have a basic understanding of how to use PeopleSoft applications, system administration, and basic server technology. You should also have a basic familiarity with PSADMIN.
Contents of this paper:
· Specifically, this paper is a compilation of published Peoplebooks, GSC Solutions and additional information. The intent is for clarification of the "official" documentation, such as PeopleBooks and Installation Guides.
· New topics that do not appear in the "official" documentation.
PeopleBooks Recommended Reading:
· PeopleSoft Integration Broker
· PeopleSoft Integration Broker Peoplebook > Configuring the Messaging System.
· PeopleSoft Server Tools Administration > Working With PSADMIN Menus
· PeopleSoft Server Tools Administration > Understanding Application Server Domain Parameters

Introducing the PeopleSoft Messaging Server
PeopleSoft Messaging Services exist on the application server and are the heart of the Integration Broker. Before using Integration Broker, you must configure and start the Messaging Server, aka PUB/SUB. Although the server processes devoted to your messaging system are all part of the larger application server domain, they comprise a distinct set of processes that aren’t involved with the ordinary transactions associated with PIA connections.
Six processes of two different types, dispatchers and handlers, are combined in pairs to produce the messaging servers needed for transmitting messages throughout your messaging system. Each messaging server is a different type. A set of three — a publication broker, a publication contractor, and a subscription contractor — constitute the messaging server set required by Integration Broker. Following is a listing of the generic names for the processes:

PeopleSoft delivers default PUB/SUB services with _dflt added to the above naming convention. For example PSBRKDSP_dflt. It is recommended that you use these services unless you have a specific need for dedicated handlers.To boot PUB/SUB use PSADMIN to configure your domain and simply answer Y to the following question at the end of the configuration process:

Command to execute (1-7, q) : 4 Do you want the Publish/Subscribe servers configured (y/n)? [y]:y

servers as the default messaging services will handle all basic messages.
Please see the PUB/SUB TUNING section of this guide for recommended values and explanations of psappsrv.cfg values
More information about managing the application server can be found in the PeopleSoft Server Tools Administration Peoplebook.
Additional Information available in Peoplebooks under: Home > PeopleBooks Library > PeopleSoft Integration Broker > Configuring the Messaging


Messaging Server Processes:

There are a variety of server processes devoted to application messaging. If you are not implementing the application messaging technology then you may skip through the delivered, default server processes. The delivered server processes are:
· PSBRKDSP
· PSBRKHND
· PSPUBDSP
· PSPUBHND
· PSSUBDSP
· PSSUBHND
These server processes act as brokers, dispatchers, and handlers of the messages in your messaging system. For the purposes of this paper we will divide these into two categories: Dipatchers and Handlers.


Configuring Messaging Servers in PSADMIN:

This section provides overviews of messaging server configuration, dispatcher parameters, and handler parameters.
Understanding Messaging Server Configuration
Once you create dedicated messaging servers, you must configure their dispatcher and handler processes so they boot when you start the application server. You configure these processes using PSADMIN just as you do any other server process that runs on the application server. Before you attempt to configure additional messaging server processes, you should be familiar with the other server processes that run on the application server.

As stated earlier, two types of server processes comprise each messaging server: a dispatcher and a handler. Each process type requires you to set a different set of parameters. Most of the parameters are similar to other server processes, such as PSSAPPSRV, but some parameters are specific to messaging servers.

Understanding Dispatcher Parameters
There are three generic process types that are the basis for all dispatcher processes:
· PSBRKDSP — the publication broker dispatcher.
· PSPUBDSP — the publication contractor dispatcher.
· PSSUBDSP — the subscription contractor dispatcher.
The following parameters apply to all three process types.


Recycle Count
Specifies the number of times each dispatcher process will be executed before being terminated (intentionally) by the system and then immediately restarted.
Servers must be intermittently recycled to clear buffer areas. The time required to recycle a server is negligible—occurring in milliseconds. Recycle Count does not translate into a native Tuxedo parameter in the PSAPPSRV.UBB file. Instead the value is stored in memory and is managed by the system.


Allowed Consec Service Failures
This option allows for dynamic server process restarts in the event of service failures.
To enable this option, enter a number greater than zero, and to disable this option enter 0. The default value for this parameter is 2. The value you enter is the number of consecutive service failures that will 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, but if they do it indicates that the server process needs to be recycled or cleansed. A “Retry” message appears when the number of service failures you specified occurs.


Handler Status Checkcount
Handler check count is used to determine how often the dispatcher should look to get the number of associated handlers.
The value of Handler Status Checkcount is the number of cycles that the dispatcher will perform before reading the MIB and getting the number of associated handlers. This comes into play when the number of handlers change (add more, some crash etc.) by having the proper count , the dispatcher can queue up messages to the handler more efficiently. Also if there are no handlers, then the dispatcher will not queue up any publications causing the application server log to fill up.
For 8.4 it is simply used to determine if there are any handlers, and if not don't send the message to the handler. This is to eliminate any the informational messages in the appserv.log if the handlers are down. For 8.42 it is used to merely look at see if any associated handler is booted. Going forward 8.43 it will be used as one of the determinate of how much work should the dispatcher send out at one time.


Scan Interval
Specifies the number of seconds between scans of the work queue when idle.
The scan interval is necessary to detect messages published from two-tier connections, because 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 that two-tier messages get processed in a timely manner. The scan interval is analogous to the Process Scheduler polling the Process Request table. In addition, the scan interval detects messages that have been resubmitted after an error, for example. Decreasing the scan interval will decrease latency for two-tier publishes and error recovery


Ping Rate
Used for PSPUBDSP only.
After this many seconds of inactivity, the server will scan the database queues and restart any stalled/crashed items. The scan rate and Ping rate (as percentage) will determine the actual interval for pinging any unavailable remote nodes (algorithm used: Attempts * Ping Rate * Scan Inteval).


Maximum Ping Interval
The maximum Ping Interval (in Hours) is the maximum interval between subsequent attempted pings of any unavailable remote nodes.


Memory Queue Refresh Rate
PeopleSoft Integration Broker maintains current asynchronous messaging queues in system memory for quick access. On rare occasions these cached queues can become corrupted, at which point they must be refreshed from the Integration Broker data tables. The likelihood and frequency of cache corruption depends on a combination of factors specific to your 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 your situation.
Each dispatcher on your 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 channel. For example, with a memory queue refresh rate of 8, multiple channels could have up to seven dispatch attempts each without triggering any refresh. The following settings are also significant:
· A setting of 0 disables the refresh altogether. This is the default value.
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 will reduce the latency for recovering stalled items with a status of Started. However, under high load, items might stay in the Started state longer than normal for valid reasons — all the handlers might be busy, and the handler service request for the item might be queued at the Tuxedo level. Setting the restart period too low will result in redundant restarts — the dispatcher will dispatch the item again, even though the original request is still in the Tuxedo queue. A small number of extra restarts is benign, but 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) / (# of handlers)) * (average processing time per request)
For example, if you have an incoming rate of twenty per second, and you have four handlers, each handler will be busy processing one item and will have four others waiting in the queue. A new item will have to wait for the currently processing item, plus the four enqueued items, before it will be 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.

Understanding Handler Parameters

There are three generic process types that are the basis for all handler processes:
· PSBRKHND — the publication broker handler.
· PSPUBHND — the publication contractor handler.
· PSSUBHND — the subscription contractor handler.
The following parameters apply to all three process types.

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

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

Service Timeout
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 terminate itself and Tuxedo automatically restarts the process.

Recycle Count
Specifies the number of times the system executes each server before PeopleSoft intentionally terminates the process.
Server processes must be intermittently recycled to clear buffer areas. The time required to recycle a server is negligible—occurring in milliseconds. Recycle Count does not translate into a native Tuxedo parameter in the PSAPPSRV.UBB file. Instead the value is stored in memory and is managed by PeopleSoft.

Allowed Consec Service Failures
This option allows for dynamic server process restarts in the event of service failures.
To enable this option, enter a number greater than zero, and to disable this option enter 0. The default for this parameter is 2. The numerical value you enter is the number of consecutive service failures that will 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, but if they do it indicates that the server process needs to be recycled or cleansed. A “Retry” message appears when the number of service failures you specified occurs.

Max Retries
Specifies the maximum number of times the server should attempt to restart a failed action.
This parameter prevents a bad item from continuously crashing a handler process — its counter is incremented when the handler sets the status to "working," but before it actually starts processing the item.

Understanding Integration Broker Parameters

The following parameter applies to the Integration Broker technology.
Min Message Size for Compression
The Min Message Size for Compression parameter enables you to configure the threshold of message before the system compresses the message.


Local Compression

The integration engine compresses and base64 encodes messages destined for the PeopleSoft listening connector on its local integration gateway, based on a setting for the application server domain in the PSAPPSRV.CFG file, which you can configure using the PSADMIN utility. The setting is a threshold message size, above which messages will be compressed. PSADMIN presents the setting as follows:
Values for config section - Integration Broker
Min Message Size For Compression=10000

Do you want to change any values (y/n)? [n]:
The value is the message size in bytes; the default value is 10000 (10 KB). You can specify a setting of 0 to compress all messages.

Minimum and Recommended Values.

Specific application server tuning needs vary by customer site based on volume and server capacity. Requests for tuning issues and assistance should be addressed to Peoplesoft Consulting. However, some specific information is available below:

PSAPPSRV should have a minimum of 3 instances booted when starting Pub/Sub.
PSBRKDSP/HND settings should be sized up. A minumum of 3 instances should be used for all application messaging scenarios.
For one particular customer I recommend increasing the PSBRKHND settings to 10/10. Same with the PUB and SUB handler settings: set min/max of 10/10. Other customers have used as many as 20 instances for PSSUBHND. This is generally a tuning issue, and settings vary greatly from site to site.
Recycle count: A single handler is restarting itself after this number services (this is not the number messages, but the number of calls from the tuxedo service). Setting this too low can create performance problems. When a service recycles itelf, all requests must wait for the handler to come back up and re-submit. It is generally recommended using 10,000 to 100,000 for this value. If you recycle your application server or pub/sub services regularly a value of 0 can be used.
Restart Period. Since restart period controls how long before a started item will be resubmitted, dispatcher requests may be resubmitting themselves over and over again resulting in a higher queue number. This can be adjusted by changing Restart Period=5 to a higher number. Customers will need to play with this and monitor results, but setting this to 120 would be better than the delivered 5 second interval, especially when using a lower value recycle count.