Consultor Eletrônico

SUMMARY:

This solution explains how to control asynchronous communication flow
with Progress SonicMQ Version 2000.x and 3.x for the JMS
Publish/Subscribe model and provides a solution to stalls.

EXPLANATION:

Where synchronous communication requires acknowledgement of every sent
message, asynchronous communication does not rely on the availability
of one of the two communicating elements.

SonicMQ achieves asynchronous communication capability by having a
message broker in the middle of peers that functions like a buffer
for the publisher and a provider for the subscribers within the
specified JMS Publish/Subscribe Model. But available resources for
that feature are not unlimited, and under specific circumstances, the
broker may seem to hang.

For example, if the publisher sends many more messages than the
slowest subscriber can receive, the buffer for the message broker may
become full and the broker cannot receive messages for the specific
topic. Here the broker appears to hang since the publisher cannot
publish further messages and a faster subscriber must wait until the
slowest one terminates the connection.

SOLUTION:

You can alter the 150000 bytedefault buffer size in the broker.ini
file by using the property:

OUTPUT_QUEUE_SIZE=<value>

Setting this parameter to a larger value allows more messages to
remain in memory for a given client (subscriber) at a given time.

The "output queue" to which this setting applies is only used for
messages being sent to clients which have not durably subscribed
to the topic. For example:

OUTPUT_QUEUE_SIZE=1500000

Reference To Written Documentation:

SonicMQ 3.0 Installation Configuration & Administration Guide,
Chapter 1, Installation

Java Message Service Specification, Sun JMS documentation page, java.sun.com/products/jms/docs