Hi HappyMan, So, architecturally speaking, this is really something that should be handled at the client/application layer using your exception handling and try/catch/finally logic. Your code should never be allowed to crash without releasing the connection, even with a hard kill of the process. Be sure then that your client is doing adequate cleanup first.
However, things like firewalls, etc, at the TCP layer can interfere here as well, so, once you are sure your client is solid, if you are still having the same issue then try turning off TCP keepalive by adding the parameter transport.useKeepAlive=false to the transport connector for MQTT in your broker.xml file, as described here: https://activemq.apache.org/tcp-transport-reference That should force the connection to disconnect after no data on the line for a specified amount of time. Your clients should be using the failover: prefix to ensure that they attempt to reconnect to make sure that any falsely disconnected clients are able to come back up. Hope that helps!! -Justin On 10/21/19, 1:38 AM, "HappyMan" <speciali...@yandex.ru> wrote: By the way forgot to wright. When it happens (unexpectable lost connection) broker keeps this connection alive and logically it is ok because client did not send any request for disconnect. And probably this subscription keeps alive because broker still has infromation that client is connected. -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.
