Rollback scenario failed - configuration not correct?

[aevo]

Following scenario is not running with my current queue configuration. On the one side I've got an user (u1) who is sending a message to the queue, on the other there are two listener (l1 and l2).

1. u1 is sending a message to the queue
   
2. l1 reads the message, set a flag and starts working
   
3. l1 is creating a new message and send it to the queue (try to parallelize the process)
   
4. l2 is getting the message, checks for the flag and, because the flag is set, he's doing a rollback
   
5. l1 is releasing the flag and is waiting for the result of l2
   
6. l2 starts again, is checking for the flag and, because it isn't set, he's finishing the task and send a result
   
7. l1 is finishing
   
8. u1 gets the final result
   

With my current configuration (attached to the end) it's stopping after point 4. I think that the queue tries to send the rollbacked message to l1 (and not l2 again, because he already rollbacked the message), but the listener is not ready to work on a new task and so I'm in a dead lock situation, because the queue isn't sending the message again to l2.

So, what's wrong with my configuration? How can I force the queue to send the message again to l2?

<address-setting match="jms.queue.TrQueue">
  <dead-letter-address>jms.queue.TrDlQueue</dead-letter-address>
  <redelivery-delay>2000</redelivery-delay>
  <redistribution-delay>500</redistribution-delay>
  <max-delivery-attempts>3</max-delivery-attempts>
</address-setting>

[ataylor]

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!

[aevo]

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).

[aevo]

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 ...

[aevo]

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.

[timfox]

FWIW, if you're using STOMP there is no consumer flow control.

Consumer flow control is a feature of the core protocol, not STOMP.