The topics and queues are filled using a Spring JMSTemplate that has it's own connection factory, and dequeuing is done by message listeners that all have their own connection. So everything should have its own connection, let alone session.
I'll do another run on debug and see what it turns up. Adrian A wrote: > > you are running separate sessions for each of those dequeue/enqueue stats? > > in my flow control tests even when one particular session was hung other > sessions to the same broker was fine, just when I overwhelmed broker and > GC / disk checkpointing occurred that it got really bad. > > have you turned on debugging as that although verbose is a wealth of > information! > > > > Maarten_D wrote: >> >> Hi Adrian, thanks for your response. >> >> I'm currently running tests where I have a very fast producer and a >> relatively slow consumer. The producer publishes persistent messages to a >> topic, where the enqueue and dequeue count diverge fairly rapidly to a >> difference of around 80,000 messages. The producer then gets whacked and >> the enqueue graph in visualvm completely levels off. This is more or less >> expected, as I've turned on producerFlowControl for topics. However, the >> entire broker stalls. I have several queues that are filled and emptied >> at the same time as the topic, and their dequeue/enqueue stats flatline >> as well, even though flow control shouldn't apply to them. Thats why I >> was interested to find out if you'd discovered some kind of fresh angle. >> Regards, >> Maarten >> > > -- View this message in context: http://old.nabble.com/Slow-sending-of-messages-tp26849964p27623064.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
