Browse Prior Art Database

Maintaining an optimal queue depth

IP.com Disclosure Number: IPCOM000180905D
Original Publication Date: 2009-Mar-20
Included in the Prior Art Database: 2009-Mar-20
Document File: 1 page(s) / 39K

Publishing Venue

IBM

Abstract

The deeper a message queue is, the more expensive each put to the queue becomes. In time the queue may become full if the messages continue to be put at a faster rate than they are retrieved. It is desirable to maintain an optimal queue depth. A method for keeping an optimal queue depth is described.

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

Page 1 of 1

Maintaining an optimal queue depth

The deeper a message queue is, the more expensive each "put" to the queue becomes. In time the queue may become full if the messages continue to be put at a faster rate than they are retrieved.

    It is desirable to maintain an optimal queue depth else the applications working on that queue begin to suffer the effects of slow, inefficient operations. However, it is difficult for the putting application to judge what the current flow of messages through the queue is and what action should actually be taken to keep the queue at an acceptable level - should it put the next message or not?

    In a product such as WebSphere MQ* an attribute, OPTIMUMDEPTH, is added to the message queue definition, taking an integer value which must be between zero and the maximum queue depth (inclusive).

    When an put operation is attempted the queue manager will check the current queue depth. If the current queue depth is greater than or equal to the value of the OPTIMUMDEPTH attribute then the put operation will start blocking either for the interval specified by the application, or if not specified, by the default wait interval defined in the queue definition. If, while waiting for the wait interval to be exceeded, the queue depth drops to below the OPTIMUMDEPTH value then the put operation will un-block and can continue.

    When the queue depth is one lower than the OPTIMUMDEPTH only one blocked put operation will be...