You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Albert Strasheim <13...@sun.ac.za> on 2007/05/24 22:18:40 UTC
Consumers, noLocal, Stomp and Openwire
Hello all
This question is about the behaviour of the AMQCPP library, but it
might also apply to the Java library.
I did a quick test where I created a consumer on a topic with an empty
selector and noLocal flag set to true which, according to the
documentation, should mean that the consumer doesn't receive any
messages published by its own connection.
This seems to work fine with Openwire, but when using Stomp, I seem to
be getting messages published from my own connection.
Is this a Stomp limitation or is this an issue that should be
investigated further?
Thanks.
Cheers,
Albert
Re: Consumers, noLocal, Stomp and Openwire
Posted by Albert Strasheim <fu...@gmail.com>.
Hello all
Thanks for the feedback. The mistake was on my end.
I was creating two consumers on the same Stomp connection, the first with
noLocal=false and the second with noLocal=true. Because I was using Stomp,
only the first consumer's settings have any effect (same thing as with
selectors).
When I changed my code to only create one consumer with noLocal=true, things
worked as expected, i.e., my consumer didn't receive message sent by the
producer on the same connection.
Cheers,
Albert
----- Original Message -----
From: "Hiram Chirino" <hi...@hiramchirino.com>
To: <de...@activemq.apache.org>
Sent: Thursday, June 07, 2007 12:16 AM
Subject: Re: Consumers, noLocal, Stomp and Openwire
> Technically, the no local option is supported on the STOMP subscribe
> frame so I'm not sure why it's not supported by the c++ client.
>
> On 5/31/07, Albert Strasheim <13...@sun.ac.za> wrote:
>> Hello all,
>>
>> Does anybody have any thoughts on this? I'd like to get a final answer
>> so that I can write the tests for my Python wrapper for AMQCPP
>> accordingly.
Re: Consumers, noLocal, Stomp and Openwire
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Technically, the no local option is supported on the STOMP subscribe
frame so I'm not sure why it's not supported by the c++ client.
On 5/31/07, Albert Strasheim <13...@sun.ac.za> wrote:
> Hello all,
>
> Does anybody have any thoughts on this? I'd like to get a final answer
> so that I can write the tests for my Python wrapper for AMQCPP
> accordingly.
>
> Cheers,
>
> Albert
>
> On Thu, 24 May 2007, Albert Strasheim wrote:
>
> > Hello all
> >
> > This question is about the behaviour of the AMQCPP library, but it
> > might also apply to the Java library.
> >
> > I did a quick test where I created a consumer on a topic with an empty
> > selector and noLocal flag set to true which, according to the
> > documentation, should mean that the consumer doesn't receive any
> > messages published by its own connection.
> >
> > This seems to work fine with Openwire, but when using Stomp, I seem to
> > be getting messages published from my own connection.
> >
> > Is this a Stomp limitation or is this an issue that should be
> > investigated further?
> >
> > Thanks.
> >
> > Cheers,
> >
> > Albert
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Consumers, noLocal, Stomp and Openwire
Posted by Albert Strasheim <13...@sun.ac.za>.
Hello all,
Does anybody have any thoughts on this? I'd like to get a final answer
so that I can write the tests for my Python wrapper for AMQCPP
accordingly.
Cheers,
Albert
On Thu, 24 May 2007, Albert Strasheim wrote:
> Hello all
>
> This question is about the behaviour of the AMQCPP library, but it
> might also apply to the Java library.
>
> I did a quick test where I created a consumer on a topic with an empty
> selector and noLocal flag set to true which, according to the
> documentation, should mean that the consumer doesn't receive any
> messages published by its own connection.
>
> This seems to work fine with Openwire, but when using Stomp, I seem to
> be getting messages published from my own connection.
>
> Is this a Stomp limitation or is this an issue that should be
> investigated further?
>
> Thanks.
>
> Cheers,
>
> Albert