How do I remove the old connection in a proper way? Just calling removeConnection with the old context and old info does not deactivate the durable subscriptions. if I then call removeConsumers so that the durable subscriptions get deactivated results to strange reconnect behaviour: everytime I reconnect after a connection loss, all the messages are pushed to my device and never deleted from the topic. I always receive all messages that were sent during my offline time.
Can somebody give me a hint how to solve that issue? -------- Original-Nachricht -------- > Datum: Mon, 03 Dec 2012 16:20:07 +0100 > Von: "Christian Webel" <[email protected]> > An: [email protected] > Betreff: Re: MQTT and JMS/NMS: ActiveMQ vs. Apollo > Thanks. That will be my first plugin, so let's try it :-) > > -------- Original-Nachricht -------- > > Datum: Mon, 3 Dec 2012 13:24:02 +0000 > > Von: Gary Tully <[email protected]> > > An: "[email protected]" <[email protected]> > > Betreff: Re: MQTT and JMS/NMS: ActiveMQ vs. Apollo > > > 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 <[email protected]> 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 <[email protected]> > > > > An: "[email protected]" <[email protected]> > > > > 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 <[email protected]> > > 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
