Christian, calling removeConnection should do it: just like what used to be in region broker: http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/RegionBroker.java?r1=1307142&r2=1307141&pathrev=1307142
Seems like you want cleanSession=true in your mqtt client. by default mqtt clients are durable subscribers so unless they ack, all messages will be retained by the broker. On 5 December 2012 00:27, Christian Webel <c_we...@gmx.de> wrote: > 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" <c_we...@gmx.de> > > An: users@activemq.apache.org > > 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 <gary.tu...@gmail.com> > > > An: "users@activemq.apache.org" <users@activemq.apache.org> > > > 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 <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 > -- http://redhat.com http://blog.garytully.com
