You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Matthew Karlsen <MK...@idbs.com> on 2016/04/25 10:30:11 UTC
Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works on
ActiveMQ)
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?
Thank you & regards,
Matthew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works
on ActiveMQ)
Posted by Matthew Karlsen <MK...@idbs.com>.
Thank you Gordon and Robbie for the rapid responses. I had my eye on ARTEMIS-46 when looking through the tickets a few minutes ago but the confirmation that it is actually the issue in question is much appreciated -- as is the further info on potential work-arounds.
-----Original Message-----
From: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
Sent: 25 April 2016 10:31
To: users@qpid.apache.org
Subject: Re: Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works on ActiveMQ)
On 25 April 2016 at 10:27, Robbie Gemmell <ro...@gmail.com> wrote:
> On 25 April 2016 at 10:02, Gordon Sim <gs...@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.parkAndCheckIn
>>> terrupt(AbstractQueuedSynchronizer.java:836)
>>> at
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShare
>>> dInterruptibly(AbstractQueuedSynchronizer.java:997)
>>> at
>>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedI
>>> nterruptibly(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(JmsMess
>>> ageConsumer.java:627)
>>> at
>>> org.apache.qpid.jms.JmsMessageConsumer.dequeue(JmsMessageConsumer.ja
>>> va:259)
>>> at
>>> org.apache.qpid.jms.JmsMessageConsumer.receive(JmsMessageConsumer.ja
>>> va: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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works
on ActiveMQ)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 25 April 2016 at 10:27, Robbie Gemmell <ro...@gmail.com> wrote:
> On 25 April 2016 at 10:02, Gordon Sim <gs...@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
Re: Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works
on ActiveMQ)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 25 April 2016 at 10:02, Gordon Sim <gs...@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
(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
Re: Qpid JMS 0.9.0 receive() hanging (issue relates to Artemis; works
on ActiveMQ)
Posted by Gordon Sim <gs...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org