On 25 April 2016 at 10:02, Gordon Sim <[email protected]> wrote: > 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. > > >
Hi Matthew As Gordon already beat me to saying, this likely arises because Artemis is not responding [correctly] to 'drain' requests made by the consumer (https://issues.apache.org/jira/browse/ARTEMIS-46). The client issues them if the receive timeout expires (or using noWait) and there isn't yet a message available in the consumers local prefetch buffer. You can configure the client not to do this by setting the jms.receiveLocalOnly and/or jms.receiveNoWaitLocalOnly URI option to false (http://qpid.apache.org/releases/qpid-jms-0.9.0/docs/index.html#connection-uri). Note that in the case of receiveNoWait (and browsers) in particular that may then give you different behaviour than expected as it could then fail to return messages you know are 'on the broker', but havent yet reached the consumers local buffer when the receive call is made. The second part to your scenario arises from the broker failing to satisfy the idle-timeout requirements the client requested when connecting (again configurable, this time via the amqp.idleTimeout uri option), leading the client to kill the presumed-dead connection. That should be resolved by the next broker release as changes were made in that area recently via https://issues.apache.org/jira/browse/ARTEMIS-398. Robbie --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
