activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paddy Carman <paddy.car...@gmail.com>
Subject Re: Durable subscribers (for topic) and Network of brokers
Date Wed, 04 Jun 2014 18:42:27 GMT
Thanks Christian. You are correct. C had connected to A before. The
scenario is that A and B are behind a load-balancer. When C connects
through a load balancer, it can be connected to either of the brokers. It
seems like VirtualTopics is a solution if subscribers can consume from
queues. For example, with STOMP I was able to overcome this issue using a
VirtualTopic for Publisher P and a related queue for the consumer C. But my
subscribers are using MQTT and can consume only from topics. Is there a
solution in this case?
Thanks,
PC


On Wed, Jun 4, 2014 at 10:18 AM, Christian Posta <christian.posta@gmail.com>
wrote:

> Does C connect (or did it connect previously) to A to establish that
> durable subscription on A? Or is that durable sub staying around somehow on
> A?
>
>
> On Mon, Jun 2, 2014 at 3:43 PM, Paddy Carman <paddy.carman@gmail.com>
> wrote:
>
> > Seeking the experts help here.
> >
> > I have 2 brokers - A and B - connected as networks of brokers
> configuration
> > using network connectors.
> >
> > P ------------ A -----B-------------C
> >
> > There is one publisher P connected to A that published to topic
> > /topic/foo/bar. I also have a durable subscriber C for the topic.
> > Initially C is connected to B. When P publishes message "hello1" to the
> > topic, C receives the message. Now C disconnects from B and connects to A
> > and subscribes to the same topic. Weird thing is that C received the same
> > message "hello1" again.
> >
> > Question: Is it weird or is it the expected behavior? How can I avoid C
> > from getting messages that it had already received (when it connected to
> a
> > different broker earlier)?
> >
> > I have tested this with MQTT (cleansession=0, clientid set) as well as
> > STOMP (client-id and activemq.subscriptionName values set). Both have the
> > same behavior.
> >
> > Appreciate your help!
> >
> > Thanks,
> > PC
> >
>
>
>
> --
> *Christian Posta*
> http://www.christianposta.com/blog
> twitter: @christianposta
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message