Kbase 18745: What is the WebSpeed 3.x Message Queuing Broker?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/15/2008 |
|
Status: Verified
GOAL:
What is the WebSpeed 3.x Message Queuing Broker?
GOAL:
How does client interacts with broker in webspeed 3 environment?
GOAL:
How does client interacts with broker in progress 9 environment?
GOAL:
What entries in ubroker.properties file will affect client queue?
FACT(s) (Environment):
Webspeed 3.x
FIX:
Scalability for increased load has been enhanced in Version 3.x by introduction of a "Message Queuing Broker". The concept behind this process is to create a queue in which messages/client requests can wait during time periods when ALL the agents are BUSY processing other client requests.
The Version 3.x Broker contains multiple threads, a thread for each of the Server Processes (Agent or _progres) and for each Client-Request. The key point here is that the number of 'server threads' will ALWAYS match the number of Agents and the number of 'client threads' can vary, depending on load. On a heavily used system there is now the ability to queue the Client-Requests in a Message Queue (within the Broker) until an Agent becomes available. This guarantees significantly less overhead handling retry attempts to the broker, and fewer response messages of "No Agents are Available".
In order to monitor the number of Client-Requests, you can query the status of the Broker (wtbman -name <webspeed_broker_name> -query) and track the number of
'Active Clients'. If all the agents are BUSY and there are client requests waiting to be processed, the 'Active Clients' number will be greater than the number of BUSY agents.
Within the ubroker.properties file, there is the ability to configure aspects of the Message Queuing Broker as well as other aspects of the WebSpeed broker. Please see the ubroker.properties file for more information.
requestTimeout REQUIRED
Specifies the amount of time, in seconds, the broker will wait for a server to become available for processing a request. After this timeout has expired the client will receive a "no servers available" error message.
Default: 15
maxClientInstance OPTIONAL
The maximum number of client connections the broker can support concurrently. The default value for this is set high enough to indicate the client connections is unlimited. Realistically, however the system-level resources needed to support an unlimited number of clients may be exhausted before this limit is reached.
If you see broker log entries that contain Exception Messages for "out of space" -or- "OutOfMemory" you may need to reduce this value to a more reasonable value. Lowering this value can result in client requests being rejected (Exceeded Max
Clients). Configuring and starting multiple brokers to handle higher client loads will mitigate the problem.
Default: 512