I'm experiencing the same problem -- I have two queues (A and B). They're
serviced with 40 sessions that have consumers with message listeners for
both A and B. If I send a bigger batch of messages to A, everything dies
down because message listeners for A also send to B. That is, I have 40
sessions that both consume from B and produce to B (sometimes when they get
dispatched a message from A).
Once B becomes biggish, everything stops as all consumers for B are also
producers for it, and their threads get blocked. Rather unpleasant. Also,
whenever I create a producer, I explicitly call
producer.setDeliveryMode(DeliveryMode.PERSISTENT);
so these should be all persistent queues. Regardless, I see my threads on
the client being blocked at
"session Task" daemon prio=7 tid=0x0052f1c0 nid=0x1967e00 in Object.wait()
[f0f0d000..f0f0eaa0]
at java.lang.Object.wait(Native Method)
- waiting on <0x61011860> (a
edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar)
at java.lang.Object.wait(Object.java:429)
at
edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar.await(CondVar.java:75)
- locked <0x61011860> (a
edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar)
at
edu.emory.mathcs.backport.java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:318)
at
org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:38)
at
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:70)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1108)
at
org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1524)
at
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:462)
at
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:356)
and what's even more interesting also at
"Thread-2" prio=5 tid=0x0052ead0 nid=0x1a43200 in Object.wait()
[f0e8d000..f0e8daa0]
at java.lang.Object.wait(Native Method)
- waiting on <0x623a2828> (a
edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar)
at java.lang.Object.wait(Object.java:429)
at
edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar.await(CondVar.java:75)
- locked <0x623a2828> (a
edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar)
at
edu.emory.mathcs.backport.java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:318)
at
org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:38)
at
org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:70)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1108)
at
org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1636)
at
org.apache.activemq.ActiveMQMessageConsumer.<init>(ActiveMQMessageConsumer.java:186)
at
org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:812)
at
org.apache.activemq.ActiveMQSession.createConsumer(ActiveMQSession.java:772)
that is, in consumer creation code. Now, regardless of how loaded the server
believes it is, it seems like a bad idea to me to prevent it from creating
new consumers that could provide some relief...
The server threads are blocked in
"tcp:///127.0.0.1:55094" daemon prio=9 tid=0x0055fba0 nid=0x1bb5200 in
Object.wait() [f1921000..f1922aa0]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:429)
at
org.apache.activemq.memory.UsageManager.waitForSpace(UsageManager.java:85)
- locked <0x4c9932f8> (a java.lang.Object)
at
org.apache.activemq.memory.UsageManager.waitForSpace(UsageManager.java:82)
at org.apache.activemq.broker.region.Queue.send(Queue.java:248)
at
org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:195)
at
org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:320)
at
org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:192)
at
org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:109)
at
org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:97)
at
org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:121)
at
org.apache.activemq.broker.AbstractConnection.processMessage(AbstractConnection.java:346)
at
org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:590)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:196)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:93)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70)
at
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:114)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:139)
at java.lang.Thread.run(Thread.java:552)
For the record, all I got is one queue ("A") with 5469 messages (each of
them a text message of few hundred bytes at most), one with 223 messages
(20-30k serialized object in each), one with 1328 messages ("B") (1-2K), and
one with 46 messages (few k each). On JMX console MemoryPercentageUsed of
each queue is reported to be 0.
Using ActiveMQ-4.0RC3 on Mac OS X 10.4.6,in out-of-the box configuration
(just running bin/activemq)
--
View this message in context:
http://www.nabble.com/Broker+Hung+With+Following+VM+Dump-t1627677.html#a4642576
Sent from the ActiveMQ - User forum at Nabble.com.
