Browse Prior Art Database

Message.GroupId--affinity in workload-balancing clusters of messaging systems

IP.com Disclosure Number: IPCOM000195874D
Publication Date: 2010-May-20
Document File: 3 page(s) / 51K

Publishing Venue

The IP.com Prior Art Database

Abstract

We disclose a method for load balancing in a messaging system which uses Message Grouping. The destination is determined by performing a hash of the Group Identifier, and mapping this against a list of possible valid destinations. Messages with the same Group Identifier are therefore routed to the same destination.

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

Page 1 of 3

Message.GroupId--affinity in workload-balancing clusters of messaging systems

Commercial messaging systems such as WebSphere MQ* and those specified by the JMS standard support a feature known as Message Grouping. This allows messages which are related to each other to be conveniently located, sequenced and processed together by a consuming application program.

    Current messaging systems only correctly support this functionality in a workload-balancing cluster if a single application program puts all of the messages in a group within a single session, and uses the resolve-destination-on-open option (MQOO

_ON

             OPEN in WebSphere MQ). The effect of this option is that all messages put in the same session are sent to the same destination queue via the same route. As a result, workload balancing cluster technology cannot be indiscriminately deployed to alleviate the load on an existing application system which uses Message Grouping.

    Proposed is a solution to this which would allow workload balancing to be used without requiring the application programs to be modified.

    It does not matter to which valid destination the messages are sent, provided that all members of any group are sent to the same valid destination.

    When deciding to which destination a messaging engine should route a given message, it shall do the following:
1) If the message is not part of a group, route it with current technology and ignore the following
2) Prepare (or read from a cache) an ordered list of possible destinations within the cluster
3) Prepare (or read from a cache) the number of possible destinations within the cluster
4) Use a hash function to convert the Message's GroupId field to a number between 0 and (number of destinations - 1) inclusive
5) Look up the destination at that index in the destinations list
6)Send the message to that destination
Note that the hash function should be uniform. It should spread the output

values as evenly as possible over it's output range, even if the input values are not evenly spread out.

Here is some pseudo-code that illustrates the concept:

ValidDestination
whereShouldThisGoThen(JMSMessage msg, ValidDestination dests[]) {

String GroupId;

int index;

GroupId = msg.getStringProperty(JmsConstants.JMSX

_GROUPID);

_BIND

_

if (GroupId == null)

return oldStyleRouting(msg, dests);
/* If you keep the dests list sorted you don't need this line: */ Arrays.sort(dests);

index = GroupId.getHash() % dests.length;

return dests[index]; }

The same algorithm can be realised in any language. For interoperability, all

1

Page 2 of 3

messaging engines in the workload-balancing cluster must use the same algorithm.

    The same algorithm can be used with trivial modifications to route messages with the same MessageId or CorrelationId to the same destination rather than GroupId - this is more likely to be used for performance than functional requirements.

    The list of valid destinations must be invariant to ensure the continuous operation of this algorithm. If...