Hi Guys,
I'm joining this thread a little late.
Options using browsers with a separate queue to remove messages aught to
work well.
Another option would be to use QMF to remove messages the QMF queue
management object has a purge method that can remove messages from a
queue, though unfortunately I'm pretty sure that it'll only delete n x
messages from the end of the queue so isn't really any more selective
than simply consuming messages.
This may be a dumb thought and I've not actually messed around with it
to check if it works, but surely (unless I'm mistaken....) messages
don't get removed from a queue until they are acknowledged.
In fact I'm pretty certain of this as I was whining the other week that
JMS client side Message Selectors didn't work properly because they
selected OK but never acknowledged so the messages remained on the queue.
Sooooo
Rather than using queue browsers and all that faff couldn't you simply
use JMS in client acknowledge mode rather than auto acknowledge??
http://docs.oracle.com/javaee/5/api/
When a consumer actually wants to remove the message then that consumer
would finally call acknowledge() on the message.
I'm fairly sure using transactions and having only the consumer who
actually wants to delete the messages perform a commit would have a
similar effect.
I must stress that I've not actually tried this with qpid but I think it
should work and feels cleaner than using browsers.
I guess that there might be gotchas as non-acknowledged messages will I
think get redelivered to all clients, I'm not sure what the redelivery
approach is but depending on how your client works you might need to
cater for this (checking message IDs against those of messages you've
already handled might work).
Also wrt Android consumer, as has been said there are issues (JNDI). I'm
currently working on a REST API - it's fun talking to qpid from my iPad
:-) at the moment my current focus is on a RESTful export of the QMF2
API 'cause I'm writing a whizzy HTML5/AJAX broker management interface,
but I'll be adding messaging stuff to that IDC. It's a little way off
being at the sort of quality I'd want to share, but it feels a pragmatic
approach for mobile devices at the moment.
Regards and HTH
Frase
On 25/04/12 15:30, [email protected] wrote:
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"<[email protected]>
Sent: Wednesday, April 25, 2012 10:12am
To: [email protected]
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,<[email protected]> 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"<[email protected]>
Sent: Wednesday, April 25, 2012 9:52am
To: [email protected]
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,<[email protected]> 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"<[email protected]>
Sent: Wednesday, April 25, 2012 9:14am
To: [email protected]
Cc: "Luiz Gustavo Pozzo"<[email protected]>
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: [email protected]
To: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
