Browse Prior Art Database

A mechanism for optimizing message selections by allowing messaging engines to store last best found message positions across different consumers who are using message selectors for selecting of messages.

IP.com Disclosure Number: IPCOM000199919D
Publication Date: 2010-Sep-21
Document File: 6 page(s) / 154K

Publishing Venue

The IP.com Prior Art Database

Abstract

Selection of messages using Message Selectors are a common pattern in today’s messaging environment. Consumers use message selectors to retrieve messages both in point to point and publish/subscribe domain. Using message selectors to retrieve message is always a costly operation and does induce performance problems in retrieving messages. There is a continuous effort to build new algorithms that are optimized and can retrieve messages faster with higher throughput even when message selectors are used.

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

Page 1 of 6

A mechanism for optimizing message selections by allowing messaging engines to store last best found message positions across different consumers who are using message selectors for selecting of messages .

Selection of messages using Message Selectors are a common pattern in today's messaging environment. Consumers use message selectors to retrieve messages both in point to point and

publish/subscribe domain. Using message selectors to retrieve message is always a costly

operation and does induce performance problems in retrieving messages.

There is a continuous effort to build new algorithms that are optimized and can retrieve messages faster with higher throughput even when message selectors are used.

Prior-Art

WMQ v7 introduced a new optimized way of selecting messages when message selectors are used. The message selection algorithm was moved to the queue manager so that only the matching messages are sent to the clients. WMQ v7 has a feature such that the queue manager remembers the current position for each getter which is using a selection string.

For example:

If there are 1000 Messages in the queue.

The first 995 messages have the selector Color=BLUE . Messages at 996, 997 and 998 have COLOR=GREEN and Messages at 999 and 1000 have COLOR=RED .

If the application opens the queue with selection string " COLOR=GREEN ", the first get operation will try matching the first 995 messages without success before finding a match on the 996th message. However, the second get will remember that no earlier messages matched and will only have to try matching the 997th message. This only works if the application keeps the queue open . The moment the application closes the MQOPEN handle, the index or the current position is lost and when the application reconnects a new search is performed from 1 to 996 till the message with selection string " COLOR=GREEN " is found.

Also, the current message selection algorithm designed is restricted to only one single connection . WMQ v7 currently maintains separate message positions for different connections. So if there are 100 consumers connecting from different systems to the same queue using the same selector string, the queue manager stores 100 different indexes for each of the consumer. If a new consumer is created, the queue manager will again start scanning for messages from top of the queue till the suitable message is found which could be still time consuming.

Imagine a queue having 1 million messages and there are 100 consumers connecting to this queue fetching messages using message selectors. Currently, the queue manager scans the queue 100 times the entire queue for suitable messages.

Another significant limitation with the current algorithm is that the queue manager just remembers the position of the current message selector being used by the consumer. Considering the above example, if a consumer is connected to retrieve COLOR=RED messages, the queue manager will only remember or store the...