We had a problem (with version 5.2.0, using topics and durable subscriptions) where all producers would lock up when we used producer flow control. What's strange is that the producers were not explicitly waiting in ActiveMQMessageProducer in the call to producerWindow.waitForSpace(). Instead, the producers were blocked waiting for acks. But the problem went away when we disabled producer flow control.
Can anyone shed any light on this? For what it is worth (I am new to ActiveMQ), here is what I was able to come up with. As I traced through the ActiveMQ code to try to understand what might be happening, I found myself with two concerns: (1) Possibly pertinent to Josip Gracin's observation above (11/3/08), I am concerned that the calculation of available flow-control-window is based on totalling the message sizes as measured by the producer and subtracting the message sizes as measured by the consumer (or at least by whatever ends up producing the ack). But the code in org.apache.activemq.command.Message#getSize() is a bit complex; how sure are we that the same size will be reported across marshalling/unmarshalling operations and in different contexts? (2) In trying to understand how enabling producer flow-control might have left the producer waiting forever for an ack that never came, I see fairly complex code in org.apache.activemq.broker.region.Topic#send that schedules a deferred ack when the topic is full. I believe our consumers are functioning correctly (and indeed our whole system works once we disable producer flow-control), so I don't see how any topic remained full forever – yet, our producers wound up waiting for acks forever. So I am suspicious that the acks deferred by messagesWaitingForSpace.add(new Runnable() {...} may, under some circumstances, never get sent. -- View this message in context: http://www.nabble.com/all-producer-threads-block-in-surprising-way-when-producer-flow-control-enabled-tp20685965p20685965.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.