The JMS spec does not specify in what order messages are delivered when there are multiple consumers on a queue. HornetQ will round robin consumers which is what is happening here. when the message from l2 is reolled back the next consumer that receives the message is l1. This is delivered to the consumer even tho it is currently handing a message because consumers buffer messages internally.
You could set the consumer window size to 1 message and the message will be delivered to l2 again as l1 is flagged as busy, however this will result in poor performance (which is why most JMS vendors use client side bufferering).
To be honest your use case seems a bit convoluted, maybe a rethink as to what you want your application to so is needed, maybe using Selectors or topics!
Thanks a lot for your feedback, I set "consumer-window-size" to zero and now it's running as expected. For now it's fine (maybe I will optimize it later by using selectors).
Is there a change in the "consumer-window-size" parameter handling between 2.0.0.GA and 2.1.2.Final? I used the default hornetq configuration (stand-alone, non-clustered), added the stomp acceptor and set the "consumer-window-size" parameter:
# cat hornetq-jms.xml <configuration xmlns="urn:hornetq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd"> <connection-factory name="NettyConnectionFactory"> <connectors> <connector-ref connector-name="netty"/> </connectors> <entries> <entry name="/ConnectionFactory"/> <entry name="/XAConnectionFactory"/> </entries> </connection-factory> <connection-factory name="NettyThroughputConnectionFactory"> <connectors> <connector-ref connector-name="netty-throughput"/> </connectors> <entries> <entry name="/ThroughputConnectionFactory"/> <entry name="/XAThroughputConnectionFactory"/> </entries> <consumer-window-size>0</consumer-window-size> </connection-factory> ...
But the messages are cached on the user side, when I use 2.1.2.Final. What is going wrong? According to the documentation (and the example) it should work ...
Please ignore my last post. It seems that the consumer is the reason for the behavior - I will do some tests and give a response later. I apologize for the trouble caused.
FWIW, if you're using STOMP there is no consumer flow control.
Consumer flow control is a feature of the core protocol, not STOMP.