Qpid › Apache Qpid users

Duplating Messages

Classic

List

Threaded

30 messages Options

Luiz Gustavo Pozzo

Duplating Messages

Hello,
Is there a way to have multiple clients connected to a queue and all of them receive all the messages from this queue?
Thanks.

Jakub Scholz-2

Re: Duplating Messages

Hi,

You can connect in the "browsing" mode - the client will then only
read the messages. You can then connect multiple clients to one queue.
The side effect is, that the messages will always stay in the queue -
which may not be what you always want.

The browsing mode is enabled from the destination address. For example:
source_queue; { node: { type: queue } , create: sender , mode: browse }

It is also a bit described in the docu:
http://qpid.apache.org/books/0.14/Programming-In-Apache-Qpid/html/ch02s04.html#id548242

Regards
Jakub

On Tue, Apr 24, 2012 at 19:09, Luiz Gustavo Pozzo <[hidden email]> wrote:
>
> Hello,
> Is there a way to have multiple clients connected to a queue and all of them receive all the messages from this queue?
> Thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Gordon Sim

Re: Duplating Messages

In reply to this post by Luiz Gustavo Pozzo

On 04/24/2012 06:09 PM, Luiz Gustavo Pozzo wrote:
> Is there a way to have multiple clients connected to a queue and all of them receive all the messages from this queue?

You can have them subscribe as browsers rather than consumers. However
in that case you need to think about how the messages will be removed.

Can you explain the context for the question? Why do you want this
pattern as opposed to say having a pub-sub pattern (where each
subscriber has their own private subscription queue with a copy of each
message on it). That might help with further suggestions.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Luiz Gustavo Pozzo

RE: Duplating Messages

Thanks for answering,
My problem is, I should have the same user logged in 2 differents devices (ex: pc and smartphone), in this case I want to make sure he receives the same message in both devices, but in the moment he take some action over this message I have to remove it from queue. Woking with only one kill for the same user seems like the easier way.

> Date: Wed, 25 Apr 2012 09:00:32 +0100
> From: [hidden email]
> To: [hidden email]
> Subject: Re: Duplating Messages
>
> On 04/24/2012 06:09 PM, Luiz Gustavo Pozzo wrote:
> > Is there a way to have multiple clients connected to a queue and all of them receive all the messages from this queue?
>
> You can have them subscribe as browsers rather than consumers. However
> in that case you need to think about how the messages will be removed.
>
> Can you explain the context for the question? Why do you want this
> pattern as opposed to say having a pub-sub pattern (where each
> subscriber has their own private subscription queue with a copy of each
> message on it). That might help with further suggestions.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Alan Conway

Re: Duplating Messages

On 04/25/2012 08:45 AM, Luiz Gustavo Pozzo wrote:
>
> Thanks for answering,
> My problem is, I should have the same user logged in 2 differents devices (ex: pc and smartphone), in this case I want to make sure he receives the same message in both devices, but in the moment he take some action over this message I have to remove it from queue. Woking with only one kill for the same user seems like the easier way

Another option is to use a "fanout" exchange. Each receiver binds a private
queue to the exchange and your sender sends messages to the exchange. A fanout
exchange sends each message it receives to all of the queues bound to it.

>> Date: Wed, 25 Apr 2012 09:00:32 +0100
>> From: [hidden email]
>> To: [hidden email]
>> Subject: Re: Duplating Messages
>>
>> On 04/24/2012 06:09 PM, Luiz Gustavo Pozzo wrote:
>>> Is there a way to have multiple clients connected to a queue and all of them receive all the messages from this queue?
>>
>> You can have them subscribe as browsers rather than consumers. However
>> in that case you need to think about how the messages will be removed.
>>
>> Can you explain the context for the question? Why do you want this
>> pattern as opposed to say having a pub-sub pattern (where each
>> subscriber has their own private subscription queue with a copy of each
>> message on it). That might help with further suggestions.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

m.luchak

Re: Duplating Messages

Hi All,

The issue we (I am working with Luiz) are trying to solve is that we need a durable queue subscribed to a topic exchange. We are calling this the UserQueue. This queue needs to be read concurrently by the same human user connecting with multiple "devices" (web client, Android, desktop). These devices must receive all of the messages on the queue.

Currently we are using RabbitMQ and it is not possible to have two devices connected concurrently to the same queue that receive all of the messages.

Round robin is not an option as we need all connected devices to receive all of the messages at the same time.

Using temporary queues to subscribe to the exchange is not an option as we need to receive messages that were published when the human user was not logged on with any device.

Here's our idea;

TopicExchange -> UserQueue (durable) <-- Multiple Concurrent Users (receive all messages)

We are looking at using browse to enable this functionality. Does this seem doable?

thanks for all your help,
Matthew

-----Original Message-----
From: "Alan Conway" <[hidden email]>
Sent: Wednesday, April 25, 2012 9:14am
To: [hidden email]
Cc: "Luiz Gustavo Pozzo" <[hidden email]>
Subject: Re: Duplating Messages

On 04/25/2012 08:45 AM, Luiz Gustavo Pozzo wrote:
>
> Thanks for answering,
> My problem is, I should have the same user logged in 2 differents devices (ex: pc and smartphone), in this case I want to make sure he receives the same message in both devices, but in the moment he take some action over this message I have to remove it from queue. Woking with only one kill for the same user seems like the easier way

Another option is to use a "fanout" exchange. Each receiver binds a private
queue to the exchange and your sender sends messages to the exchange. A fanout
exchange sends each message it receives to all of the queues bound to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Rob Godfrey

Re: Duplating Messages

There are certainly ways of achieving this result... which language
client (language) and which broker (C++ or Java) are you looking to
use?

Cheers,
Rob

On 25 April 2012 15:41, <[hidden email]> wrote:

>
> Hi All,
>
> The issue we (I am working with Luiz) are trying to solve is that we need a durable queue subscribed to a topic exchange. We are calling this the UserQueue. This queue needs to be read concurrently by the same human user connecting with multiple "devices" (web client, Android, desktop). These devices must receive all of the messages on the queue.
>
> Currently we are using RabbitMQ and it is not possible to have two devices connected concurrently to the same queue that receive all of the messages.
>
> Round robin is not an option as we need all connected devices to receive all of the messages at the same time.
>
> Using temporary queues to subscribe to the exchange is not an option as we need to receive messages that were published when the human user was not logged on with any device.
>
> Here's our idea;
>
> TopicExchange -> UserQueue (durable) <-- Multiple Concurrent Users (receive all messages)
>
> We are looking at using browse to enable this functionality. Does this seem doable?
>
> thanks for all your help,
> Matthew
>
> -----Original Message-----
> From: "Alan Conway" <[hidden email]>
> Sent: Wednesday, April 25, 2012 9:14am
> To: [hidden email]
> Cc: "Luiz Gustavo Pozzo" <[hidden email]>
> Subject: Re: Duplating Messages
>
>
>
> On 04/25/2012 08:45 AM, Luiz Gustavo Pozzo wrote:
>>
>> Thanks for answering,
>> My problem is, I should have the same user logged in 2 differents devices (ex: pc and smartphone), in this case I want to make sure he receives the same message in both devices, but in the moment he take some action over this message I have to remove it from queue. Woking with only one kill for the same user seems like the easier way
>
> Another option is to use a "fanout" exchange. Each receiver binds a private
> queue to the exchange and your sender sends messages to the exchange. A fanout
> exchange sends each message it receives to all of the queues bound to it.
>
>
>>> Date: Wed, 25 Apr 2012 09:00:32 +0100
>>> From: [hidden email]
>>> To: [hidden email]
>>> Subject: Re: Duplating Messages
>>>
>>> On 04/24/2012 06:09 PM, Luiz Gustavo Pozzo wrote:
>>>> Is there a way to have multiple clients connected to a queue and all of them receive all the messages from this queue?
>>>
>>> You can have them subscribe as browsers rather than consumers. However
>>> in that case you need to think about how the messages will be removed.
>>>
>>> Can you explain the context for the question? Why do you want this
>>> pattern as opposed to say having a pub-sub pattern (where each
>>> subscriber has their own private subscription queue with a copy of each
>>> message on it). That might help with further suggestions.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Gordon Sim

Re: Duplating Messages

In reply to this post by m.luchak

On 04/25/2012 02:41 PM, [hidden email] wrote:

Receiving the messages through two (or more) browsers is certainly
possible. The problem as I see it is how you then remove these messages.

One option that is possible using AMQP 0-10 is to have one of the
browsers acquire and accept the message. This is only possible using a
client library that directly exposes the 0-10 commands which is less
than ideal.

An alternative is to start a separate consumer to actually consume the
messages that have been processed.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

m.luchak

Re: Duplating Messages

In reply to this post by Rob Godfrey

Hi Rob,

That's great to hear!! We are using Java clients for web and Android. As far as the broker is concerned if the performance is equal we would opt for Java.. For furthur discussion we can assume that we are using Java clients and the Java broker running on Ubuntu 11.10 64bit.

thanks very much,
Matthew

-----Original Message-----
From: "Rob Godfrey" <[hidden email]>
Sent: Wednesday, April 25, 2012 9:52am
To: [hidden email]
Subject: Re: Duplating Messages

There are certainly ways of achieving this result... which language
client (language) and which broker (C++ or Java) are you looking to
use?

Cheers,
Rob

On 25 April 2012 15:41, <[hidden email]> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Rob Godfrey

Re: Duplating Messages

OK... so as Gordon says in his e-mail, there's two basic approaches
one can take... either attempting to use the lower level AMQP 0-10
commands to selectively consume messages at the client, or to separate
out the browsing and consuming into separate activities (e.g. one
pattern I have seen is to set up one consumer in a "browse only" mode
and then for each message you want to "consume" create a consumer with
a selector matching the message id of the message... obviously this
has a higher overhead however).

Both brokers will support both these approaches, the Java Broker
supports the older AMQP 0-9-1 protocol in addition to 0-10 which I
mention in case you have been using any particular client libraries
with RabbitMQ (Rabbit speaks AMQP 0-9-1 and not AMQP 0-10).

In terms of the Qpid clients, our Java client doesn't really offer an
easy API (or a supported one) for accessing the 0-10 protocol
directly, instead being focused on JMS. the pattern described above
can be used from the JMS API, the only issue is that we may need to do
a bit of work to get the client running on Android - I think someone
was highlighting the use of JNDI being an issue there.

Cheers,
Rob

On 25 April 2012 16:02, <[hidden email]> wrote:

>
> Hi Rob,
>
> That's great to hear!! We are using Java clients for web and Android. As far as the broker is concerned if the performance is equal we would opt for Java.. For furthur discussion we can assume that we are using Java clients and the Java broker running on Ubuntu 11.10 64bit.
>
> thanks very much,
> Matthew
>
> -----Original Message-----
> From: "Rob Godfrey" <[hidden email]>
> Sent: Wednesday, April 25, 2012 9:52am
> To: [hidden email]
> Subject: Re: Duplating Messages
>
>
>
> There are certainly ways of achieving this result... which language
> client (language) and which broker (C++ or Java) are you looking to
> use?
>
> Cheers,
> Rob
>
> On 25 April 2012 15:41, <[hidden email]> wrote:
>>
>> Hi All,
>>
>> The issue we (I am working with Luiz) are trying to solve is that we need a durable queue subscribed to a topic exchange. We are calling this the UserQueue. This queue needs to be read concurrently by the same human user connecting with multiple "devices" (web client, Android, desktop). These devices must receive all of the messages on the queue.
>>
>> Currently we are using RabbitMQ and it is not possible to have two devices connected concurrently to the same queue that receive all of the messages.
>>
>> Round robin is not an option as we need all connected devices to receive all of the messages at the same time.
>>
>> Using temporary queues to subscribe to the exchange is not an option as we need to receive messages that were published when the human user was not logged on with any device.
>>
>> Here's our idea;
>>
>> TopicExchange -> UserQueue (durable) <-- Multiple Concurrent Users (receive all messages)
>>
>> We are looking at using browse to enable this functionality. Does this seem doable?
>>
>> thanks for all your help,
>> Matthew
>>
>> -----Original Message-----
>> From: "Alan Conway" <[hidden email]>
>> Sent: Wednesday, April 25, 2012 9:14am
>> To: [hidden email]
>> Cc: "Luiz Gustavo Pozzo" <[hidden email]>
>> Subject: Re: Duplating Messages
>>
>>
>>
>> On 04/25/2012 08:45 AM, Luiz Gustavo Pozzo wrote:
>>>
>>> Thanks for answering,
>>> My problem is, I should have the same user logged in 2 differents devices (ex: pc and smartphone), in this case I want to make sure he receives the same message in both devices, but in the moment he take some action over this message I have to remove it from queue. Woking with only one kill for the same user seems like the easier way
>>
>> Another option is to use a "fanout" exchange. Each receiver binds a private
>> queue to the exchange and your sender sends messages to the exchange. A fanout
>> exchange sends each message it receives to all of the queues bound to it.
>>
>>
>>>> Date: Wed, 25 Apr 2012 09:00:32 +0100
>>>> From: [hidden email]
>>>> To: [hidden email]
>>>> Subject: Re: Duplating Messages
>>>>
>>>> On 04/24/2012 06:09 PM, Luiz Gustavo Pozzo wrote:
>>>>> Is there a way to have multiple clients connected to a queue and all of them receive all the messages from this queue?
>>>>
>>>> You can have them subscribe as browsers rather than consumers. However
>>>> in that case you need to think about how the messages will be removed.
>>>>
>>>> Can you explain the context for the question? Why do you want this
>>>> pattern as opposed to say having a pub-sub pattern (where each
>>>> subscriber has their own private subscription queue with a copy of each
>>>> message on it). That might help with further suggestions.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

m.luchak

Re: Duplating Messages

Thanks guys!!

We are going to first try the direct approach : a modified client that will browse all message and selectively consume. We will get back to you with our findings... (and more questions for sure ;)

thanks again,

Matthew

-----Original Message-----
From: "Rob Godfrey" <[hidden email]>
Sent: Wednesday, April 25, 2012 10:12am
To: [hidden email]
Subject: Re: Duplating Messages

OK... so as Gordon says in his e-mail, there's two basic approaches
one can take... either attempting to use the lower level AMQP 0-10
commands to selectively consume messages at the client, or to separate
out the browsing and consuming into separate activities (e.g. one
pattern I have seen is to set up one consumer in a "browse only" mode
and then for each message you want to "consume" create a consumer with
a selector matching the message id of the message... obviously this
has a higher overhead however).

Both brokers will support both these approaches, the Java Broker
supports the older AMQP 0-9-1 protocol in addition to 0-10 which I
mention in case you have been using any particular client libraries
with RabbitMQ (Rabbit speaks AMQP 0-9-1 and not AMQP 0-10).

In terms of the Qpid clients, our Java client doesn't really offer an
easy API (or a supported one) for accessing the 0-10 protocol
directly, instead being focused on JMS. the pattern described above
can be used from the JMS API, the only issue is that we may need to do
a bit of work to get the client running on Android - I think someone
was highlighting the use of JNDI being an issue there.

Cheers,
Rob

On 25 April 2012 16:02, <[hidden email]> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

m.luchak

Re: Duplating Messages

In reply to this post by Rob Godfrey

Hey All,

Moving forward with concurrent reads on a queue... Browse works like a charm.. Now, any insight on how to selectively remove a message from a queue? If possible I would like to avoid creating a consumer(with messageID) just for this as it seems a little cludgy.. The only delete method I have seen is by cmd line which tells me that it's possible but I'm ignorant of the calls...

thanks for all your help,
Matthew

-----Original Message-----
From: "Rob Godfrey" <[hidden email]>
Sent: Wednesday, April 25, 2012 10:12am
To: [hidden email]
Subject: Re: Duplating Messages

OK... so as Gordon says in his e-mail, there's two basic approaches
one can take... either attempting to use the lower level AMQP 0-10
commands to selectively consume messages at the client, or to separate
out the browsing and consuming into separate activities (e.g. one
pattern I have seen is to set up one consumer in a "browse only" mode
and then for each message you want to "consume" create a consumer with
a selector matching the message id of the message... obviously this
has a higher overhead however).

Both brokers will support both these approaches, the Java Broker
supports the older AMQP 0-9-1 protocol in addition to 0-10 which I
mention in case you have been using any particular client libraries
with RabbitMQ (Rabbit speaks AMQP 0-9-1 and not AMQP 0-10).

In terms of the Qpid clients, our Java client doesn't really offer an
easy API (or a supported one) for accessing the 0-10 protocol
directly, instead being focused on JMS. the pattern described above
can be used from the JMS API, the only issue is that we may need to do
a bit of work to get the client running on Android - I think someone
was highlighting the use of JNDI being an issue there.

Cheers,
Rob

On 25 April 2012 16:02, <[hidden email]> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Rob Godfrey

Re: Duplating Messages

There's no real underlying protocol primitive that maps to "delete a
message". The way AMQP works is that you get sent messages and then
you can (in 0-10 at least) choose to accept responsibility for the
message (thus allowing the server to delete it), or decide not to do
so. Browsing vs. consuming is essentially just the difference between
whether the recipient has got a lock on the message while they are
deciding on not.

If you are working with the low level protocol you can thus construct
something to "browse" and then selectively delete (acknowledge), but
this isn't really made visible through the JMS API.

If you're interested in what might be involved in implementing such an
API you can try to get your head round the client side selector code
in the JMS client... Since the C++ broker doesn't yet implement server
side selectors, the client works by getting a copy of all messages,
and then only exposing to the user those that match the selector. [The
Java Broker does implement server side selectors, so this code is not
necessary when connecting to the Java Broker].

However, if I were you I would look to see if the kludge-y solution
gives acceptable performance/overhead as I think trying to engineer
the above is not a simple/small task.

Going forward we'll hopefully be re-engineering the Java client such
that it sits atop a more generic messaging API as is seen in the Qpid
C++ and Python clients. This would give a better opportunity to use
functionality not easily expressible through the JMS APIs.

Cheers,
Rob

On 26 April 2012 20:27, <[hidden email]> wrote:

>
> Hey All,
>
> Moving forward with concurrent reads on a queue... Browse works like a charm.. Now, any insight on how to selectively remove a message from a queue? If possible I would like to avoid creating a consumer(with messageID) just for this as it seems a little cludgy.. The only delete method I have seen is by cmd line which tells me that it's possible but I'm ignorant of the calls...
>
> thanks for all your help,
> Matthew
>
> -----Original Message-----
> From: "Rob Godfrey" <[hidden email]>
> Sent: Wednesday, April 25, 2012 10:12am
> To: [hidden email]
> Subject: Re: Duplating Messages
>
>
>
> OK... so as Gordon says in his e-mail, there's two basic approaches
> one can take... either attempting to use the lower level AMQP 0-10
> commands to selectively consume messages at the client, or to separate
> out the browsing and consuming into separate activities (e.g. one
> pattern I have seen is to set up one consumer in a "browse only" mode
> and then for each message you want to "consume" create a consumer with
> a selector matching the message id of the message... obviously this
> has a higher overhead however).
>
> Both brokers will support both these approaches, the Java Broker
> supports the older AMQP 0-9-1 protocol in addition to 0-10 which I
> mention in case you have been using any particular client libraries
> with RabbitMQ (Rabbit speaks AMQP 0-9-1 and not AMQP 0-10).
>
> In terms of the Qpid clients, our Java client doesn't really offer an
> easy API (or a supported one) for accessing the 0-10 protocol
> directly, instead being focused on JMS. the pattern described above
> can be used from the JMS API, the only issue is that we may need to do
> a bit of work to get the client running on Android - I think someone
> was highlighting the use of JNDI being an issue there.
>
> Cheers,
> Rob
>
> On 25 April 2012 16:02, <[hidden email]> wrote:
>>
>> Hi Rob,
>>
>> That's great to hear!! We are using Java clients for web and Android. As far as the broker is concerned if the performance is equal we would opt for Java.. For furthur discussion we can assume that we are using Java clients and the Java broker running on Ubuntu 11.10 64bit.
>>
>> thanks very much,
>> Matthew
>>
>> -----Original Message-----
>> From: "Rob Godfrey" <[hidden email]>
>> Sent: Wednesday, April 25, 2012 9:52am
>> To: [hidden email]
>> Subject: Re: Duplating Messages
>>
>>
>>
>> There are certainly ways of achieving this result... which language
>> client (language) and which broker (C++ or Java) are you looking to
>> use?
>>
>> Cheers,
>> Rob
>>
>> On 25 April 2012 15:41, <[hidden email]> wrote:
>>>
>>> Hi All,
>>>
>>> The issue we (I am working with Luiz) are trying to solve is that we need a durable queue subscribed to a topic exchange. We are calling this the UserQueue. This queue needs to be read concurrently by the same human user connecting with multiple "devices" (web client, Android, desktop). These devices must receive all of the messages on the queue.
>>>
>>> Currently we are using RabbitMQ and it is not possible to have two devices connected concurrently to the same queue that receive all of the messages.
>>>
>>> Round robin is not an option as we need all connected devices to receive all of the messages at the same time.
>>>
>>> Using temporary queues to subscribe to the exchange is not an option as we need to receive messages that were published when the human user was not logged on with any device.
>>>
>>> Here's our idea;
>>>
>>> TopicExchange -> UserQueue (durable) <-- Multiple Concurrent Users (receive all messages)
>>>
>>> We are looking at using browse to enable this functionality. Does this seem doable?
>>>
>>> thanks for all your help,
>>> Matthew
>>>
>>> -----Original Message-----
>>> From: "Alan Conway" <[hidden email]>
>>> Sent: Wednesday, April 25, 2012 9:14am
>>> To: [hidden email]
>>> Cc: "Luiz Gustavo Pozzo" <[hidden email]>
>>> Subject: Re: Duplating Messages
>>>
>>>
>>>
>>> On 04/25/2012 08:45 AM, Luiz Gustavo Pozzo wrote:
>>>>
>>>> Thanks for answering,
>>>> My problem is, I should have the same user logged in 2 differents devices (ex: pc and smartphone), in this case I want to make sure he receives the same message in both devices, but in the moment he take some action over this message I have to remove it from queue. Woking with only one kill for the same user seems like the easier way
>>>
>>> Another option is to use a "fanout" exchange. Each receiver binds a private
>>> queue to the exchange and your sender sends messages to the exchange. A fanout
>>> exchange sends each message it receives to all of the queues bound to it.
>>>
>>>
>>>>> Date: Wed, 25 Apr 2012 09:00:32 +0100
>>>>> From: [hidden email]
>>>>> To: [hidden email]
>>>>> Subject: Re: Duplating Messages
>>>>>
>>>>> On 04/24/2012 06:09 PM, Luiz Gustavo Pozzo wrote:
>>>>>> Is there a way to have multiple clients connected to a queue and all of them receive all the messages from this queue?
>>>>>
>>>>> You can have them subscribe as browsers rather than consumers. However
>>>>> in that case you need to think about how the messages will be removed.
>>>>>
>>>>> Can you explain the context for the question? Why do you want this
>>>>> pattern as opposed to say having a pub-sub pattern (where each
>>>>> subscriber has their own private subscription queue with a copy of each
>>>>> message on it). That might help with further suggestions.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

m.luchak

Re: Duplating Messages

thanks Rob... I agree that it's not a trivial task... going for the straight forward approach of creating a new connection to select and ack the message using ... JMSMessageID I guess?... will try it out...

thanks again,
Matthew

-----Original Message-----
From: "Rob Godfrey" <[hidden email]>
Sent: Thursday, April 26, 2012 2:48pm
To: [hidden email]
Subject: Re: Duplating Messages

There's no real underlying protocol primitive that maps to "delete a
message". The way AMQP works is that you get sent messages and then
you can (in 0-10 at least) choose to accept responsibility for the
message (thus allowing the server to delete it), or decide not to do
so. Browsing vs. consuming is essentially just the difference between
whether the recipient has got a lock on the message while they are
deciding on not.

If you are working with the low level protocol you can thus construct
something to "browse" and then selectively delete (acknowledge), but
this isn't really made visible through the JMS API.

If you're interested in what might be involved in implementing such an
API you can try to get your head round the client side selector code
in the JMS client... Since the C++ broker doesn't yet implement server
side selectors, the client works by getting a copy of all messages,
and then only exposing to the user those that match the selector. [The
Java Broker does implement server side selectors, so this code is not
necessary when connecting to the Java Broker].

However, if I were you I would look to see if the kludge-y solution
gives acceptable performance/overhead as I think trying to engineer
the above is not a simple/small task.

Going forward we'll hopefully be re-engineering the Java client such
that it sits atop a more generic messaging API as is seen in the Qpid
C++ and Python clients. This would give a better opportunity to use
functionality not easily expressible through the JMS APIs.

Cheers,
Rob

On 26 April 2012 20:27, <[hidden email]> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Rob Godfrey

Re: Duplating Messages

You shouldn't need a new connection... just another consumer on the
same session of the same connection should be sufficient (connections
are heavy/slow to create... consumers are much lighter weight).

Cheers,
Rob

On 26 April 2012 20:59, <[hidden email]> wrote:

>
> thanks Rob... I agree that it's not a trivial task... going for the straight forward approach of creating a new connection to select and ack the message using ... JMSMessageID I guess?... will try it out...
>
> thanks again,
> Matthew
>
> -----Original Message-----
> From: "Rob Godfrey" <[hidden email]>
> Sent: Thursday, April 26, 2012 2:48pm
> To: [hidden email]
> Subject: Re: Duplating Messages
>
>
>
> There's no real underlying protocol primitive that maps to "delete a
> message". The way AMQP works is that you get sent messages and then
> you can (in 0-10 at least) choose to accept responsibility for the
> message (thus allowing the server to delete it), or decide not to do
> so. Browsing vs. consuming is essentially just the difference between
> whether the recipient has got a lock on the message while they are
> deciding on not.
>
> If you are working with the low level protocol you can thus construct
> something to "browse" and then selectively delete (acknowledge), but
> this isn't really made visible through the JMS API.
>
> If you're interested in what might be involved in implementing such an
> API you can try to get your head round the client side selector code
> in the JMS client... Since the C++ broker doesn't yet implement server
> side selectors, the client works by getting a copy of all messages,
> and then only exposing to the user those that match the selector. [The
> Java Broker does implement server side selectors, so this code is not
> necessary when connecting to the Java Broker].
>
> However, if I were you I would look to see if the kludge-y solution
> gives acceptable performance/overhead as I think trying to engineer
> the above is not a simple/small task.
>
> Going forward we'll hopefully be re-engineering the Java client such
> that it sits atop a more generic messaging API as is seen in the Qpid
> C++ and Python clients. This would give a better opportunity to use
> functionality not easily expressible through the JMS APIs.
>
> Cheers,
> Rob
>
>
>
> On 26 April 2012 20:27, <[hidden email]> wrote:
>>
>> Hey All,
>>
>> Moving forward with concurrent reads on a queue... Browse works like a charm.. Now, any insight on how to selectively remove a message from a queue? If possible I would like to avoid creating a consumer(with messageID) just for this as it seems a little cludgy.. The only delete method I have seen is by cmd line which tells me that it's possible but I'm ignorant of the calls...
>>
>> thanks for all your help,
>> Matthew
>>
>> -----Original Message-----
>> From: "Rob Godfrey" <[hidden email]>
>> Sent: Wednesday, April 25, 2012 10:12am
>> To: [hidden email]
>> Subject: Re: Duplating Messages
>>
>>
>>
>> OK... so as Gordon says in his e-mail, there's two basic approaches
>> one can take... either attempting to use the lower level AMQP 0-10
>> commands to selectively consume messages at the client, or to separate
>> out the browsing and consuming into separate activities (e.g. one
>> pattern I have seen is to set up one consumer in a "browse only" mode
>> and then for each message you want to "consume" create a consumer with
>> a selector matching the message id of the message... obviously this
>> has a higher overhead however).
>>
>> Both brokers will support both these approaches, the Java Broker
>> supports the older AMQP 0-9-1 protocol in addition to 0-10 which I
>> mention in case you have been using any particular client libraries
>> with RabbitMQ (Rabbit speaks AMQP 0-9-1 and not AMQP 0-10).
>>
>> In terms of the Qpid clients, our Java client doesn't really offer an
>> easy API (or a supported one) for accessing the 0-10 protocol
>> directly, instead being focused on JMS. the pattern described above
>> can be used from the JMS API, the only issue is that we may need to do
>> a bit of work to get the client running on Android - I think someone
>> was highlighting the use of JNDI being an issue there.
>>
>> Cheers,
>> Rob
>>
>> On 25 April 2012 16:02, <[hidden email]> wrote:
>>>
>>> Hi Rob,
>>>
>>> That's great to hear!! We are using Java clients for web and Android. As far as the broker is concerned if the performance is equal we would opt for Java.. For furthur discussion we can assume that we are using Java clients and the Java broker running on Ubuntu 11.10 64bit.
>>>
>>> thanks very much,
>>> Matthew
>>>
>>> -----Original Message-----
>>> From: "Rob Godfrey" <[hidden email]>
>>> Sent: Wednesday, April 25, 2012 9:52am
>>> To: [hidden email]
>>> Subject: Re: Duplating Messages
>>>
>>>
>>>
>>> There are certainly ways of achieving this result... which language
>>> client (language) and which broker (C++ or Java) are you looking to
>>> use?
>>>
>>> Cheers,
>>> Rob
>>>
>>> On 25 April 2012 15:41, <[hidden email]> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> The issue we (I am working with Luiz) are trying to solve is that we need a durable queue subscribed to a topic exchange. We are calling this the UserQueue. This queue needs to be read concurrently by the same human user connecting with multiple "devices" (web client, Android, desktop). These devices must receive all of the messages on the queue.
>>>>
>>>> Currently we are using RabbitMQ and it is not possible to have two devices connected concurrently to the same queue that receive all of the messages.
>>>>
>>>> Round robin is not an option as we need all connected devices to receive all of the messages at the same time.
>>>>
>>>> Using temporary queues to subscribe to the exchange is not an option as we need to receive messages that were published when the human user was not logged on with any device.
>>>>
>>>> Here's our idea;
>>>>
>>>> TopicExchange -> UserQueue (durable) <-- Multiple Concurrent Users (receive all messages)
>>>>
>>>> We are looking at using browse to enable this functionality. Does this seem doable?
>>>>
>>>> thanks for all your help,
>>>> Matthew
>>>>
>>>> -----Original Message-----
>>>> From: "Alan Conway" <[hidden email]>
>>>> Sent: Wednesday, April 25, 2012 9:14am
>>>> To: [hidden email]
>>>> Cc: "Luiz Gustavo Pozzo" <[hidden email]>
>>>> Subject: Re: Duplating Messages
>>>>
>>>>
>>>>
>>>> On 04/25/2012 08:45 AM, Luiz Gustavo Pozzo wrote:
>>>>>
>>>>> Thanks for answering,
>>>>> My problem is, I should have the same user logged in 2 differents devices (ex: pc and smartphone), in this case I want to make sure he receives the same message in both devices, but in the moment he take some action over this message I have to remove it from queue. Woking with only one kill for the same user seems like the easier way
>>>>
>>>> Another option is to use a "fanout" exchange. Each receiver binds a private
>>>> queue to the exchange and your sender sends messages to the exchange. A fanout
>>>> exchange sends each message it receives to all of the queues bound to it.
>>>>
>>>>
>>>>>> Date: Wed, 25 Apr 2012 09:00:32 +0100
>>>>>> From: [hidden email]
>>>>>> To: [hidden email]
>>>>>> Subject: Re: Duplating Messages
>>>>>>
>>>>>> On 04/24/2012 06:09 PM, Luiz Gustavo Pozzo wrote:
>>>>>>> Is there a way to have multiple clients connected to a queue and all of them receive all the messages from this queue?
>>>>>>
>>>>>> You can have them subscribe as browsers rather than consumers. However
>>>>>> in that case you need to think about how the messages will be removed.
>>>>>>
>>>>>> Can you explain the context for the question? Why do you want this
>>>>>> pattern as opposed to say having a pub-sub pattern (where each
>>>>>> subscriber has their own private subscription queue with a copy of each
>>>>>> message on it). That might help with further suggestions.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Gordon Sim

Re: Duplating Messages

In reply to this post by m.luchak

On 04/26/2012 07:59 PM, [hidden email] wrote:
> going for the straight forward approach of creating a new connection to select and ack the message using ... JMSMessageID I guess?... will try it out...

This has the advantage of being easily transferable to 1.0 if/when needed.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

m.luchak

Re: Duplating Messages

hey.. me again ;)

not sure if I'm doing this right... creating a consumer with JMSMessageID as a selector but it's not returning the message even though this message does exist (checked 5 times ;).

code:
MessageConsumer acker = (MessageConsumer) session.createConsumer(ack,"JMSMessageID=8165b87f-8e8e-3e97-991f-51b5e45fefab");

MapMessage m = (MapMessage)acker.receive();

LOG:
main 2012-04-26 17:51:23,901 DEBUG [apache.qpid.filter.JMSSelectorFilter] Created JMSSelectorFilter with selector:JMSMessageID=8165b87f-8e8e-3e97-991f-51b5e45fefab

-----Original Message-----
From: "Gordon Sim" <[hidden email]>
Sent: Thursday, April 26, 2012 3:02pm
To: [hidden email]
Subject: Re: Duplating Messages

On 04/26/2012 07:59 PM, [hidden email] wrote:
> going for the straight forward approach of creating a new connection to select and ack the message using ... JMSMessageID I guess?... will try it out...

This has the advantage of being easily transferable to 1.0 if/when needed.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

m.luchak

Re: Duplating Messages

Just some more detailed info (tried messageID as this is being returned by the logs). Any help greatly appreciated..

LOG:

main 2012-04-26 18:13:09,728 DEBUG [apache.qpid.transport.Connection] SEND: [conn:10ea9ba] ch=0 id=9 MessageSubscribe(queue=test_queue, destination=2, acceptMode=EXPLICIT, acquireMode=NOT_ACQUIRED, resumeTtl=0, arguments={x-filter-jms-selector=messageId=8165b87f-8e8e-3e97-991f-51b5e45fefab})

IoReceiver - localhost/127.0.0.1:5672 2012-04-26 18:13:09,758 DEBUG [apache.qpid.transport.Session] ID: [0] 4
IoReceiver - localhost/127.0.0.1:5672 2012-04-26 18:13:09,758 DEBUG [apache.qpid.client.AMQSession] Message[org.apache.qpid.client.message.UnprocessedMessage_0_10@b1cd0] received in session
IoReceiver - localhost/127.0.0.1:5672 2012-04-26 18:13:09,760 DEBUG [apache.qpid.transport.Connection] RECV: [conn:10ea9ba] ch=0 MessageTransfer(destination=1, acceptMode=EXPLICIT, acquireMode=NOT_ACQUIRED)
MessageProperties(contentLength=435, messageId=8165b87f-8e8e-3e97-991f-51b5e45fefab, contentType=amqp/map, userId=[B@190a0d6, applicationHeaders={price=0.99, name=Widget, Id=444444444})
DeliveryProperties(priority=MEDIUM, deliveryMode=PERSISTENT, timestamp=1335469525112, exchange=, routingKey=test_queue)

-----Original Message-----
From: [hidden email]
Sent: Thursday, April 26, 2012 4:56pm
To: [hidden email]
Subject: Re: Duplating Messages

hey.. me again ;)

not sure if I'm doing this right... creating a consumer with JMSMessageID as a selector but it's not returning the message even though this message does exist (checked 5 times ;).

code:
MessageConsumer acker = (MessageConsumer) session.createConsumer(ack,"JMSMessageID=8165b87f-8e8e-3e97-991f-51b5e45fefab");

MapMessage m = (MapMessage)acker.receive();

LOG:
main 2012-04-26 17:51:23,901 DEBUG [apache.qpid.filter.JMSSelectorFilter] Created JMSSelectorFilter with selector:JMSMessageID=8165b87f-8e8e-3e97-991f-51b5e45fefab

-----Original Message-----
From: "Gordon Sim" <[hidden email]>
Sent: Thursday, April 26, 2012 3:02pm
To: [hidden email]
Subject: Re: Duplating Messages

On 04/26/2012 07:59 PM, [hidden email] wrote:
> going for the straight forward approach of creating a new connection to select and ack the message using ... JMSMessageID I guess?... will try it out...

This has the advantage of being easily transferable to 1.0 if/when needed.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

m.luchak

Re: Duplating Messages

Eessh... bordering on spam...

ok... got the selector pulling selected messages by:

producer -> m.setIntProperty("Id", 444444444);

consumer -> MessageConsumer acker = (MessageConsumer) session.createConsumer(ack,"Id=444444444");

-----Original Message-----
From: [hidden email]
Sent: Thursday, April 26, 2012 5:17pm
To: [hidden email]
Subject: Re: Duplating Messages

Just some more detailed info (tried messageID as this is being returned by the logs). Any help greatly appreciated..

LOG:

main 2012-04-26 18:13:09,728 DEBUG [apache.qpid.transport.Connection] SEND: [conn:10ea9ba] ch=0 id=9 MessageSubscribe(queue=test_queue, destination=2, acceptMode=EXPLICIT, acquireMode=NOT_ACQUIRED, resumeTtl=0, arguments={x-filter-jms-selector=messageId=8165b87f-8e8e-3e97-991f-51b5e45fefab})

IoReceiver - localhost/127.0.0.1:5672 2012-04-26 18:13:09,758 DEBUG [apache.qpid.transport.Session] ID: [0] 4
IoReceiver - localhost/127.0.0.1:5672 2012-04-26 18:13:09,758 DEBUG [apache.qpid.client.AMQSession] Message[org.apache.qpid.client.message.UnprocessedMessage_0_10@b1cd0] received in session
IoReceiver - localhost/127.0.0.1:5672 2012-04-26 18:13:09,760 DEBUG [apache.qpid.transport.Connection] RECV: [conn:10ea9ba] ch=0 MessageTransfer(destination=1, acceptMode=EXPLICIT, acquireMode=NOT_ACQUIRED)
MessageProperties(contentLength=435, messageId=8165b87f-8e8e-3e97-991f-51b5e45fefab, contentType=amqp/map, userId=[B@190a0d6, applicationHeaders={price=0.99, name=Widget, Id=444444444})
DeliveryProperties(priority=MEDIUM, deliveryMode=PERSISTENT, timestamp=1335469525112, exchange=, routingKey=test_queue)

-----Original Message-----
From: [hidden email]
Sent: Thursday, April 26, 2012 4:56pm
To: [hidden email]
Subject: Re: Duplating Messages

hey.. me again ;)

not sure if I'm doing this right... creating a consumer with JMSMessageID as a selector but it's not returning the message even though this message does exist (checked 5 times ;).

code:
MessageConsumer acker = (MessageConsumer) session.createConsumer(ack,"JMSMessageID=8165b87f-8e8e-3e97-991f-51b5e45fefab");

MapMessage m = (MapMessage)acker.receive();

LOG:
main 2012-04-26 17:51:23,901 DEBUG [apache.qpid.filter.JMSSelectorFilter] Created JMSSelectorFilter with selector:JMSMessageID=8165b87f-8e8e-3e97-991f-51b5e45fefab

-----Original Message-----
From: "Gordon Sim" <[hidden email]>
Sent: Thursday, April 26, 2012 3:02pm
To: [hidden email]
Subject: Re: Duplating Messages

On 04/26/2012 07:59 PM, [hidden email] wrote:
> going for the straight forward approach of creating a new connection to select and ack the message using ... JMSMessageID I guess?... will try it out...

This has the advantage of being easily transferable to 1.0 if/when needed.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Gordon Sim

Re: Duplating Messages

In reply to this post by m.luchak

On 04/26/2012 09:56 PM, [hidden email] wrote:
>
> hey.. me again ;)
>
> not sure if I'm doing this right... creating a consumer with JMSMessageID as a selector but it's not returning the message even though this message does exist (checked 5 times ;).
>
> code:
> MessageConsumer acker = (MessageConsumer) session.createConsumer(ack,"JMSMessageID=8165b87f-8e8e-3e97-991f-51b5e45fefab");

Have you tried with single quotes around the id? i.e.
"JMSMessageID='8165b87f-8e8e-3e97-991f-51b5e45fefab'"

> MapMessage m = (MapMessage)acker.receive();
>
> LOG:
> main 2012-04-26 17:51:23,901 DEBUG [apache.qpid.filter.JMSSelectorFilter] Created JMSSelectorFilter with selector:JMSMessageID=8165b87f-8e8e-3e97-991f-51b5e45fefab
>
> -----Original Message-----
> From: "Gordon Sim"<[hidden email]>
> Sent: Thursday, April 26, 2012 3:02pm
> To: [hidden email]
> Subject: Re: Duplating Messages
>
>
>
> On 04/26/2012 07:59 PM, [hidden email] wrote:
>> going for the straight forward approach of creating a new connection to select and ack the message using ... JMSMessageID I guess?... will try it out...
>
> This has the advantage of being easily transferable to 1.0 if/when needed.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]