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 <[email protected]> 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/
