qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works on ActiveMQ)
Date Mon, 25 Apr 2016 09:31:12 GMT
On 25 April 2016 at 10:27, Robbie Gemmell <robbie.gemmell@gmail.com> wrote:
> On 25 April 2016 at 10:02, Gordon Sim <gsim@redhat.com> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message