You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Milano Nicolum <dr...@gmail.com> on 2017/01/20 15:33:01 UTC
ActiveMQConnection close() hangs on pending message
Hi, I'm using ActiveMQ 5.14.3 with Qpid JMS client 0.20.0 in QueueBridge
setup when local and remote queues are connected via JmsConnector. On my
device I have an osgi bundle sending and receiving messages. ActiveMQ
servers as persistence manager (KahaDB) and as entry point for the system,
while Qpid JMS client as actual communication client for connection to MS
Azure's IoT Hub.
This device suffers from quite common losses of network connection. In such
case I try to close the JmsConnector and free all resources belonging to
it. The problem is that when there is a message pending (cannot be
delivered since the network connection is lost) my implementation of
JmsConnector gets stuck on closing local connection.
the closing process hangs on:
FifoMessageDispatchChannel.stop(), line 124
ActiveMQMessageConsumer.stop(), line 1551
ActiveMQSession.stop(), line 1856
ActiveMQConnection.doStop(false), line 586
ActiveMQConnection.close(),line 642
It is clear to me that the session tries to finish its pending receives
first, but is there any way how to shut the connection down in given time?
The way the close() is done means the stopping thread gets stuck before the
ActiveMQConnection.closeTimeout has any chance to get checked...
Thanks for any tips!
Re: ActiveMQConnection close() hangs on pending message
Posted by Milano Nicolum <dr...@gmail.com>.
I'd say that duplicate is expected to be sent anyway in such case. As I can never be sure if I can reconnect in one minute, one hour or if I can reconnect at all. In this case some detection of chanel inactivity works fine on qpid, but I haven't found any timeout which would prevent closing of the local connection from getting stuck.
Also if the device is shutting down I cannot wait for the stop indefinitely. And have to close everything as fast as possible. If there is a message in flight it has to wait for ack till next device start. (And hopefully it will not expire).
Am I missing any useful settings for cases described above?
20. 1. 2017 20:18, 20:18, Timothy Bish <ta...@gmail.com> napsal/a:
>On 01/20/2017 10:33 AM, Milano Nicolum wrote:
>> Hi, I'm using ActiveMQ 5.14.3 with Qpid JMS client 0.20.0 in
>QueueBridge
>> setup when local and remote queues are connected via JmsConnector. On
>my
>> device I have an osgi bundle sending and receiving messages. ActiveMQ
>> servers as persistence manager (KahaDB) and as entry point for the
>system,
>> while Qpid JMS client as actual communication client for connection
>to MS
>> Azure's IoT Hub.
>>
>> This device suffers from quite common losses of network connection.
>In such
>> case I try to close the JmsConnector and free all resources belonging
>to
>> it. The problem is that when there is a message pending (cannot be
>> delivered since the network connection is lost) my implementation of
>> JmsConnector gets stuck on closing local connection.
>>
>> the closing process hangs on:
>> FifoMessageDispatchChannel.stop(), line 124
>> ActiveMQMessageConsumer.stop(), line 1551
>> ActiveMQSession.stop(), line 1856
>> ActiveMQConnection.doStop(false), line 586
>> ActiveMQConnection.close(),line 642
>>
>> It is clear to me that the session tries to finish its pending
>receives
>> first, but is there any way how to shut the connection down in given
>time?
>> The way the close() is done means the stopping thread gets stuck
>before the
>> ActiveMQConnection.closeTimeout has any chance to get checked...
>>
>> Thanks for any tips!
>>
>From what I can see the client is doing what the JMS specification has
>mandated it do which is to wait for the delivery of the message to
>complete before allowing the resource to close. If it doesn't do that
>then you can end up with duplicate deliveries as the message won't get
>ack'd and on reconnect the broker will send it to you again.
>
>The only way around that would be to add configuration to tell it to
>only wait a certain amount of time before assuming the delivery is
>stuck
>and not going to complete, then you have to tune that to account for
>those who have onMessage perform often lengthly operations.
>
>
>--
>Tim Bish
>twitter: @tabish121
>blog: http://timbish.blogspot.com/
Re: ActiveMQConnection close() hangs on pending message
Posted by Timothy Bish <ta...@gmail.com>.
On 01/20/2017 10:33 AM, Milano Nicolum wrote:
> Hi, I'm using ActiveMQ 5.14.3 with Qpid JMS client 0.20.0 in QueueBridge
> setup when local and remote queues are connected via JmsConnector. On my
> device I have an osgi bundle sending and receiving messages. ActiveMQ
> servers as persistence manager (KahaDB) and as entry point for the system,
> while Qpid JMS client as actual communication client for connection to MS
> Azure's IoT Hub.
>
> This device suffers from quite common losses of network connection. In such
> case I try to close the JmsConnector and free all resources belonging to
> it. The problem is that when there is a message pending (cannot be
> delivered since the network connection is lost) my implementation of
> JmsConnector gets stuck on closing local connection.
>
> the closing process hangs on:
> FifoMessageDispatchChannel.stop(), line 124
> ActiveMQMessageConsumer.stop(), line 1551
> ActiveMQSession.stop(), line 1856
> ActiveMQConnection.doStop(false), line 586
> ActiveMQConnection.close(),line 642
>
> It is clear to me that the session tries to finish its pending receives
> first, but is there any way how to shut the connection down in given time?
> The way the close() is done means the stopping thread gets stuck before the
> ActiveMQConnection.closeTimeout has any chance to get checked...
>
> Thanks for any tips!
>
From what I can see the client is doing what the JMS specification has
mandated it do which is to wait for the delivery of the message to
complete before allowing the resource to close. If it doesn't do that
then you can end up with duplicate deliveries as the message won't get
ack'd and on reconnect the broker will send it to you again.
The only way around that would be to add configuration to tell it to
only wait a certain amount of time before assuming the delivery is stuck
and not going to complete, then you have to tune that to account for
those who have onMessage perform often lengthly operations.
--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/