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, <[email protected]> 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" <[email protected]> > Sent: Thursday, April 26, 2012 2:48pm > To: [email protected] > 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, <[email protected]> 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" <[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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
