Browse Prior Art Database

Group open exclusive for a message queue

IP.com Disclosure Number: IPCOM000181416D
Original Publication Date: 2009-Apr-01
Included in the Prior Art Database: 2009-Apr-01
Document File: 2 page(s) / 45K

Publishing Venue

IBM

Abstract

This idea allows a group of co-operating applications to share exclusive access to a message queue.

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

Page 1 of 2

Group open exclusive for a message queue

A program is disclosed that allows a group of co-operating message queueing applications to consume messages from a shared queue while knowing that no other applications can consume messages from the same queue. Asynchronous messaging systems typically provide very coarse control over concurrent consumption of messages from a message queue, for example in WebSphere MQ* the options MQOO

_INPUT

_SHARED and MQOO

_INPUT

_EXCLUSIVE are

provided.

    Modern asynchronous messaging applications are often written using multiple threads or multiple processes so that they can scale to larger volumes of work on multi-CPU systems. Such applications often end up with multiple getter threads on the same queue. Current open exclusive behaviours are too restrictive to be useful
to this kind of application. Messaging applications often open queues in "shared input" mode so that they can take advantage of multi-threading without being restricted to a single getter thread. However, this means that other applications could consume messages from the input queue and that the application cannot take advantage of the reassurance that exclusive input provides.

    What is needed is a method for a single application (comprising multiple threads or multiple processes, possibly running on multiple machines) to request exclusive input for its own threads.

    Another current solution is to open a queue for "exclusive input" on a dedicated getter thread. The getter thread becomes the only thread able to remove messages from the queue (this has severe implications for units of work). Application programmers who want high throughput must write complex thread pooling code to hand off messages from the getter thread to a series of worker threads, serialising the data transfer correctly. It would be much simpler to write such an application if each thread could directly open the queue, secure in the knowledge that the only other getters are part of the same application.

    One example is WebSphere MQ pipelined (dual unit of work) channels. A pair of channel threads co-operate to send messages from a single transmission queue to a remote destination. Ideally only this pair of threads would be able to remove messages from the transmission queue, to the exclusion of all other threads. Currently such channels open the transmission queue for shared input, which potentially allows other threads to remove messages. This could be very disruptive to the operation of the channel.

    The system herein introduces a new method of opening a queue for exclusive input: "group open exclusive" mode.

    When a queue is first opened, the...