qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Duplating Messages
Date Fri, 27 Apr 2012 08:08:43 GMT
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, m.luchak@smartasking.com 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"<rob.j.godfrey@gmail.com>
> Sent: Wednesday, April 25, 2012 10:12am
> To: users@qpid.apache.org
> 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,<m.luchak@smartasking.com>  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"<rob.j.godfrey@gmail.com>
>> Sent: Wednesday, April 25, 2012 9:52am
>> To: users@qpid.apache.org
>> 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,<m.luchak@smartasking.com>  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"<aconway@redhat.com>
>>> Sent: Wednesday, April 25, 2012 9:14am
>>> To: users@qpid.apache.org
>>> Cc: "Luiz Gustavo Pozzo"<lgppozzo@hotmail.com>
>>> 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: gsim@redhat.com
>>>>> To: users@qpid.apache.org
>>>>> 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: users-unsubscribe@qpid.apache.org
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message