activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ddewaele <>
Subject MQTT - using allowLinkStealing to avoid InvalidClientIDException
Date Tue, 13 Jan 2015 07:03:55 GMT

We have a number of devices in the field that are connecting to ActiveMQ.
ActiveMQ is setup in a master-slave configuration with a loadbalancer in
front of it. Devices connect through the loadbalancer using the Eclipse Paho
client library.

>From time to time we are receiving the following error (at a certain point
we saw this for all of our clients and we reached a point where not a single
client was able to connect anymore)  :

This seems to happen beyond our control. The events leading up to this on
the clients is the following :

- Client receives a timeout after publishing a message

- Clients becomes disconnected (detected while trying to publish a msg)

- Client tries to reconnect but fails

- At this exact point do we see the javax.jms.InvalidClientIDException on
the ActiveMQ broker.

The documention mentions a property called allowLinkStealing that should be
enabled by default for MQTT transports.
However this issue seems to indicate it was not for 5.10.0 :

I was wondering 

- why in the scenario above didn't ActiveMQ remove the connection at the
time the client reported it was disconnected.
- In what situation could this occur ?
- why would we set allowlinkStealing=true for MQTT by default and not for
JMS for example.
- Are there side effects associated with using allowlinkStealing.

The only side-effect I can think of is the following:

Without allowLinkStealing, when a unit is connected to activeMQ with
clientID X, no other unit with the same clientID can connect and that is a
good thing. 

If I allow link stealing, a badly-configured unit in the field (with an
existing clientID) can cause havoc (by stealing the connection from the
valid unit).

But I am interested in finding out why ActiveMQ could end up in this
situation in the first place where it reports this InvalidClientIDException
after the client clearly received a disconnect.


View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message