Different failover behaviour depending on the number of outstanding messages
Issue
In case of failover, currently processed messages are handled differently, dependent on the size of messages that are send to the client.
Steps to reproduce:
- put 66 or more text messages on a queue
- start an ordinary client with failover:tcp and client ack
- after dispatch of the first message but before acknowledge, do a restart of amq (e.g. holding a breakpoint in the client).
- acknowledge the message (e.g. step further in debug); no exception is thrown
-> After stepping further, the identical message is sent to the client again!
- process some messages that you get less than 64 messages left
- do the same as above: hold the client before ack and restart the server
-> The message is auto acked and not send again: Duplicate dispatch on connection: ... to consumer: ..., ignoring (auto acking) duplicate: MessageDispatch {...} The auto acknowledge could lead to the lost of one message
We've seen that the problem with the 64 in case of client ack mode has to do with a LRU-Cache that is used in ActiveMQMessageAuditNoSync.
If a message is dispatched again after failover, there is a lookup into this cache if the message was seen at the client already.
Unfortunately the currently processed message does not seem to be into the cache if you have 65 messages to be dispatched.
Environment
Fuse Message Broker 7.1
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
