Browse Prior Art Database

More efficient client-side selection of messages

IP.com Disclosure Number: IPCOM000236211D
Publication Date: 2014-Apr-11
Document File: 2 page(s) / 37K

Publishing Venue

The IP.com Prior Art Database

Abstract

More efficient client-side selection of messages by server-side pre-selection.

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

Page 01 of 2

More efficient client-side selection of messages

At the moment there are two ways for a consumer getting messages from a destination on a queue manager to select specific messages based on their content.

Selection can be done either server-side, where the queue manager chooses

a message to give to a consumer, or client side
When client-side selection is used, what usually happens is that the entire

message, or a large initial chunk including the headers is sent to the browsing client application, where it can decide if it wants the message based on whether the

content matches the defined selector. If it does, a reference to the message is passed to the consuming thread so it can get the message.

    This can be inefficient if the messages are large - however some customers do want client-side selection either for performance, or because they do not want the extra CPU cycles on a particular queue manager caused by selection taking place there. Depending on the nature of the selector and size of the messages, this could be quite resource intensive.

    Sending the whole messages to the client can also cause a lot of unnecessary network traffic.

    The idea is to use client-side selection in the same way, but to only ask for a specific part of the message if possible by doing a small amount of pre-selection at the server side - effectively splitting the selection so a small amount is done at the server.

    So if the selector is a specific property on the message, the queue manager side can find that property and send it rather than sending the whole message - there would be some small additional overhead on the queue manager because of this, but less than sending a complete message across the network where it will be parsed in full by the client, or than fully parsing the message content to find a property which also matches the selector value at the server side. If the client has requested a property is matched, the queue manager is just taking a specified chunk of the next available message.

    If the selector is part of the message content, the client could indicate where in the body they expect the item to be, and the queue manager only sends that. So, if some application specific header is being used, or if the messages consist of some proprietary content such as some XML, the client could indicate to the server

just to send a particular attribute.

    Again, not much additional work would be needed by the queue manager for t...