qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Duplating Messages
Date Thu, 26 Apr 2012 19:01:25 GMT
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,  <m.luchak@smartasking.com> 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" <rob.j.godfrey@gmail.com>
> Sent: Thursday, April 26, 2012 2:48pm
> To: users@qpid.apache.org
> 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,  <m.luchak@smartasking.com> 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" <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
>

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


Mime
View raw message