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.
