That would be a good use of a broker plug in. override addConnection and removeConnection and if there is a duplicate clientId, remove the old connection before progressing. It may be possible to grok the protocol also and make it conditional.
Essentially, this would workaround the jms specific behaviour of keeping a one to one mapping of clientid and connection. mqtt commands are bridged to AMQ (jms like) commands. There was some logic to this effect in region broker, but it duplicated checks for duplicate connection ids in the transportConnector and broke jmssemantic of failover, see; https://issues.apache.org/jira/browse/AMQ-3792 The MQTT use case makes a strong argument for being able to disable this ( clientID) check and not having to depend on the underlying tcp behaviour to promptly clean up closed or half closes sockets. On 3 December 2012 13:12, Christian Webel <c_we...@gmx.de> wrote: > Hi, > > I can reproduce this behaviour by simply turning the mobile data (3G) off > and on again. Then, my Android service starts reconnecting to the ActiveMQ > server and fails. > > The problem is, that after reconnecting to my mobile network provider it > might happen that I get a new IP adress which requires a new connect(). > > One workaround would be to set the keepalive value to 10 to 60 seconds. > But then, I have to wait for at least that period of time after connection > loss. The disadvantage would be, that I completely loose the advantages of > MQTT since I have to send a PINGREQ every minute or so. > > Is it possible to add a kind of protocol check to ActiveMQ that allows > duplicates in clientIDs if the protocol is MQTT and then just updates the > connection? > > Best regards, > Christian > > > -------- Original-Nachricht -------- > > Datum: Mon, 3 Dec 2012 05:44:55 -0700 > > Von: Christian Posta <christian.po...@gmail.com> > > An: "users@activemq.apache.org" <users@activemq.apache.org> > > Betreff: Re: MQTT and JMS/NMS: ActiveMQ vs. Apollo > > > On the Apollo side, the "rich protocol" conversions aren't there yet: > > https://issues.apache.org/jira/browse/APLO-267 > > > > For ActiveMQ 5.7 seems like the dead connection isn't being cleaned up > > properly when it goes away. Is this something you can reproduce? > > > > > > On Mon, Dec 3, 2012 at 4:56 AM, Christian Webel <c_we...@gmx.de> wrote: > > > > > Hi, > > > > > > I'm currently trying to add mobile clients (Android, eclipse paho > client > > > API) via the MQTT protocol to our ActiveMQ and Apollo server. The other > > > clients use JMS/NMS. Transport connectors are correctly defined. > > > > > > I have experienced following problems: > > > > > > Using ActiveMQ 5.7: > > > Everthing seems to be OK. But when the mobile device looses connection > > to > > > the server (e.g. in area with no reception) and reconnects, I get an > > > javax.jms.InvalidClientIDException: Broker: localhost - Client: XXX > > already > > > connected from tcp:YYY. As the client ID is used by the server to > > identify > > > a client when it reconnects, the client has to use the same identifier > > > between connections if durable subscriptions are used. > > > > > > Can I somehow disable this clientID check in ActiveMQ? Any idea how to > > > solve that issue? > > > > > > Using Apollo: > > > Reconnect works fine, but interacting bezween JMS/NMS and mqtt clients > > is > > > not possible. It seems that there is no proper protocol conversion > > > implemented since I receive the JMS client data in mqtt as a large > > binary > > > blob. Vice versa, I receive nothing. From mqtt to mqtt clients, > > everthing > > > works perfect! > > > > > > Any ideas on that? > > > > > > Every little help is appreciated! > > > > > > Best regards, > > > Christian > > > > > > > > > > > -- > > *Christian Posta* > > http://www.christianposta.com/blog > > twitter: @christianposta > -- http://redhat.com http://blog.garytully.com
