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