On 25/04/16 09:30, Matthew Karlsen wrote:
Hello All,
Since my last post to this list I have constructed send and recv clients
using both JMS and Reactor. Overall they work well and are robust,
and fix the issues I was encountering when using Messenger (I was
on the wrong track using Reactor at one point but Robbie Gemmell
pointed out my mistake; I went away and read the AMQP spec etc.
in an effort to understand things better and it appears to
have paid off)...
However, there is one major problem that I am encountering with Qpid JMS
that I am unsure how to resolve...
Whether I use receive() with a timeout or receiveNoWait(), receive
hangs when no messages are present. More precisely, it hangs at
the UNSAFE.park(false, 0L); line of LockSupport.park():
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:97)
at org.apache.qpid.jms.JmsConnection.pull(JmsConnection.java:764)
at org.apache.qpid.jms.JmsConnection.pull(JmsConnection.java:753)
at
org.apache.qpid.jms.JmsMessageConsumer.performPullIfRequired(JmsMessageConsumer.java:627)
at org.apache.qpid.jms.JmsMessageConsumer.dequeue(JmsMessageConsumer.java:259)
at org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.java:192)
...
Once receive() has locked up it does not resume, even if I subsequently
send a message to the appropriate queue. It is eventually shaken out of this
state by the broker:
"javax.jms.JMSException: Transport closed due to the peer exceeding our requested
idle-timeout"...
I have tried using both HornetQ and Artemis as the broker. I have also tried
ActiveMQ.
It does NOT occur on ActiveMQ, so I am wondering if it is in some way related
to how the
client interacts with a particular broker...
Does anyone have any ideas as to what may be going on?
Sounds like it is the handling of the drain flag. I found
https://issues.apache.org/jira/browse/ARTEMIS-46 which may be relevant.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
