That disproves the theory that the broker is fully unresponsive due to a full GC. (It was unthinkable that it would take 10+ minutes anyway.)
Is the consumer that gets the scheduled messages on a separate queue from the other consumers? Are selectors used by any of your consumers? How many queues are you using, and do you do destination GCing (having the broker reclaim unused queues and topics)? Kevin Burton has found performance problems with the destination GC algorithm that cause unresponsiveness when the number of destinations is enormous and the rate of turnover is high; does that describe your setup by any chance? I don't expect it to, but I want to make sure. While this is happening, is the broker responsive via JMX and the web console? If so, can you browse the queues via the web console? Can you take some thread dumps while this is going on? Being able to see what's taking place at the time would be really useful, because at this point I'm taking guesses that feel unlikely and I'm running out of even those. BTW, is this reliably reproducible, or do you just have to wait for it to happen? On Aug 21, 2015 12:43 PM, "Richard Sinek" <rsi...@intouchgps.com> wrote: > I would modify my last statement to add that there is one consumer that > still > processes data while everything else is paused. What is unique about that > is > that all messages published to that queue are delayed (scheduled) messages > and I am guessing that they are handled differently internally in AMQ. > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/AMQ-pauses-sending-to-consumers-tp4701242p4701291.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
