Cases where messages are not being consumed from a queue
MQ 4.0
I have a cluster of 3 brokers. Java clients use RANDOMIZE to connect to the cluster of brokers. Message selectors are not used. My consumers are all synchronous, and connection.start() is called prior to calling MessageConsumer.receive().
What I have seen on random occassions are messages not being consumed from the queue. The problem seems to be sporadic.
I was thinking that the reason it is sporadic is because of the RANDOMIZE configuration of the client connetion / object-store.
That is, there is a possibility for the following to happen:
1) There were messages produced on a queue on broker A, but before these messages were consumed, all the consumers have been shutdown. Thus, the messages on queue stayed on broker A .... and have not been copied / clustered to the other brokers in the cluster ( As per online documentation, a queue is "copied" to other brokers only when there is a consumer for that queue on the other brokers ).
2) Then the client applications started up produced and consumers again. This time, the producers were all connected to broker B, and all consumers for the queue were also connected to broker B.
3) Because there are no other consumers for the queue on the other brokers, the messages in the queue on broker A are never consumed.
Can someone confirm that this is a possibility ?
[1385 byte] By [
j.salvo] at [2007-11-26 8:27:33]
# 1
Well ... it does seem to be the case.
I changed the object-store so that instead of using RANDOMIZE for imqAddressListBehavior, it uses PRIORITY. Therefore, all clients ( producers and consumers ) will connect to only 1 broker out of the 3 in the cluster.
After restarting all JMS clients with the new imqAddressListBehavior, there were messages in various queues in the other brokers that were not being consumed, because there are no longer any consumers on any of the other brokers.
All the messages in that broker that all JMS clients connect to are being consumed ...
Except for about 6 messages that stays in the queue for whatever reason. All consumers receiving with receive( 10000 ), and after consuming all messages above the 6, it returns without any more messages in the queue.
Well ... so much for cluster of brokers. I'll have to think of an alternative.
# 3
It seems that the only way to prevent this from happening is to do the following:
1) Have a separate administered object ( e.g. a separate.bindings file ) for producers and consumers.
2) The administered object for producers must have a connection factory where the imqAddressListBehavior = PRIORITY and have imqAddressList=broker A then broker B in that sequence.
3) The administered object for consumers must have a connection factory where the imqAddressListBehavior = PRIORITY and have imqAddressList=broker B then broker A in that sequence.
This way, there will be guaranteed consumers on the other broker, and messages will be available on both brokers.
Problem will be what if you have more than 2 brokers in the cluster ?
# 4
There are no know bugs were messages on a queue are not delivered. There are also no known issues with broker clusters and message redelivery
What acknowledge mode are you using (or are you using transactions) ?
Do you close consumers but keep sessions open ?
Are you setting any specific properties on the destination (queue delivery policy, local destination, etc) ?
Are you using selectors ?
