In our JMS based architecture 2 applications are in a Pub-Sub mode.
The logs, show the PUBlisher appliation, publishing out 7 messages ... (6 are tagged as IN-process and the 7th COMPLETED)
the logs on the SUBcriber side, do not process those 7 messages in the exact same sequence.
On the subscriber side the messages are received in the onMessage() method of the listener
our logic is dependant on the order in which they are processed.
meaning; the 6 IN-progress messages must be processed, before the final 7th COMPLETED message.
The logs show, the first 3/4 messages are processed in sequence and then
suddenly the the final 7th COMPLETED message is received in the onMessage() before the 5h/ 6th, screwing up the logic and further flow.
However if this is executed in DEBUG mode, everything is a bit slow and proceeds smoothly
PS: We are using Ative MQ as our JMS provider,
The publisher publishes to a Virtual-Topic
and subscriber consumes from a Consumer queue created on that VT.
1. I have worked on WebLogic and WebSphere JMS implementations and I am not aware of such FIFO guarantee.
2. Even if there was a guarantee and onMessage() gets called you still cannot guarantee that it will finish before other onMessage() methods that get called afterwards.
3. If FIFO sequence is very important then you can think of throttling down the number of consumers who are listening to the messages. This can be done in Weblogic via deployment descriptor and in WebSphere via admin console option for the destination.
Joined: Jul 03, 2007
I re-phrase .... instead of "gauranteed", can it be like .....can FIFO be expected ?
I am contemplating ... to set the JMSPrority in the header of the outgoig messages on the publisher side so that the messages are priotorized.
http://community.jboss.org/wiki/JMSPriority Ordering is done first on priority, then on message ID (which gets incremented per message sent). Assuming priorities for a set of messages is the same,
and you are sending a message using a single thread/session, they will be returned in the same relative order when received by a single thread consumer.
akin to the way we can priotorize Load-on-startup servlets by assigning a 'weight' in the web.xml.
your inputs please.
Joined: Feb 13, 2004
Yes I think using this approach will ensure FIFO ordering for all messages generated by a message producer (or client or session).
So for example:
1. FIFO order will be maintained if 10 messages are generated by a client/session.
2. FIFO order will not be maintained across two clients/sessions that are generating/producing 10 messages each. It will be maintained within each of the 10 messages. But not across both the clients.