activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Webel" <c_we...@gmx.de>
Subject Re: MQTT and JMS/NMS: ActiveMQ vs. Apollo
Date Wed, 05 Dec 2012 00:27:36 GMT
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_webel@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.tully@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_webel@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.posta@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_webel@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

Mime
View raw message