On 25 April 2016 at 10:27, Robbie Gemmell <[email protected]> wrote: > 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
Erm..by setting them to true, obviously :) > (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]
