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 Mon, 03 Dec 2012 15:20:07 GMT
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