Browse Prior Art Database

Put With Wait for a queued messaging system

IP.com Disclosure Number: IPCOM000015727D
Original Publication Date: 2002-Feb-15
Included in the Prior Art Database: 2003-Jun-21
Document File: 2 page(s) / 43K

Publishing Venue

IBM

Abstract

In an asynchronous message queuing solution, it can be advantageous to enable the enqueue operation of a synchronous Put operation to implement a server-controlled wait (timed blocking behaviour) when the enqueue operation cannot be performed immediately. This will be described below. In such systems, it is possible for sending applications to flood the messaging system such that a receiving application cannot keep up. The messages then build up on queues until the queues become full. When this occurs, further Put operations may fail until one or more messages are retrieved from the queue. It can be difficult to provide appropriate messaging behaviour in these circumstances, particularly if there are several queued steps between the sending and receiving applications. One known solution is for the sender to receive a failure response when the queue is full, such that the sender knows that it has to retry the Put operation until it is successful. These retries could be attempted after a time delay. The message may be placed on a dead letter queue after a certain number of unsuccessful retries, so that problem messages are not retried for ever. Nevertheless, if the sender application retries repeatedly, this has the overhead of repeated crossing of the message queueing interface. It has now been recognised that it will often be more efficient for the queue manager program that is attempting to perform the enqueue operation to wait for a timed period in case the enqueue operation can be performed successfully within the defined period. This can be implemented by providing a Put With Wait option for message Put operations. This will not solve problems where the receiving application goes completely offline, and it still leaves the option for a putting application which requires it to push information as fast as possible (by not using the Put With Wait option). However, it permits a very simple programming style for sending applications dynamically to pace their output to the rest of the system. e.g.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 2

Put With Wait for a queued messaging system

In an asynchronous message queuing solution, it can be advantageous to enable the enqueue operation of a synchronous Put operation to implement a server-controlled wait (timed blocking behaviour) when the enqueue operation cannot be performed immediately. This will be described below.

    In such systems, it is possible for sending applications to flood the messaging system such that a receiving application cannot keep up. The messages then build up on queues until the queues become full. When this occurs, further Put operations may fail until one or more messages are retrieved from the queue. It can be difficult to provide appropriate messaging behaviour in these circumstances, particularly if there are several queued steps between the sending and receiving applications.

    One known solution is for the sender to receive a failure response when the queue is full, such that the sender knows that it has to retry the Put operation until it is successful. These retries could be attempted after a time delay. The message may be placed on a dead letter queue after a certain number of unsuccessful retries, so that problem messages are not retried for ever. Nevertheless, if the sender application retries repeatedly, this has the overhead of repeated crossing of the message queueing interface.

    It has now been recognised that it will often be more efficient for the queue manager program that is attempting to perform the enqueue operation to wait for a timed period in case the enqueue operation can be performed successfully within the defined period. This can be implemented by providing a Put With Wait option for message Put operations. This will not solve problems where the receiving application goes completely offline, and it still leaves the option for a putting application which requires it to push information as fast as possible (by not using the Put With Wait option). However, it permits a very simple programming style for sending applications dynamically to pace their output to the rest of the system. e.g.

publisher --> QueueManager1 --> channel --> QueueManager2 --> publish/subscribe engine --> QueueManager2 --> subscriber.

    If the 'feeders', publisher and channel, do a Put With Wait, this will give some resistance and help to prevent them flooding the pub/sub engine, thereby helping the pub/sub engine to retain its ability to get data out to subscribers.

    Put With Wait can be simulated by any putter simply by polling retries on queue full return codes. This is not as efficient as implementing properly in the queue manager, since the putter will have to poll for a satisfactory put, with additional overhead (especially if polling interval is low), and unnecessarily reduced response (if polling interval is too high).

    The reason why a synchronous system self tunes is that the senders are throttled waiting synchronously until the system is willing to receive their messages. The "Put With Wait" option ap...