activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milano Nicolum <>
Subject Re: ActiveMQConnection close() hangs on pending message
Date Fri, 20 Jan 2017 21:04:18 GMT
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 <> 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
>> setup when local and remote queues are connected via JmsConnector. On
>> device I have an osgi bundle sending and receiving messages. ActiveMQ
>> servers as persistence manager (KahaDB) and as entry point for the
>> 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
>> 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
>> first, but is there any way how to shut the connection down in given
>> 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
>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

  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message