qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Message selection/filtering using C++ client with the Java broker
Date Wed, 26 Jun 2013 11:56:16 GMT
Hi all,

Please see below for a question/reply about message selection/filtering
using the C++ client API and the Java broker.

On 24 June 2013 15:45, Xavier Millieret <xavier.millieret.info@gmail.com>wrote:

> Hi Robbie,
> I would like implement a request/reply but with a filter based on the
> correlationId.
> I did with the JMS api:
> Session session = connection.createSession(false,
> Destination destination = session.createQueue("myQueue");
> session.createConsumer(destination,
> "JMSCorrelationID='"+correlationId+"'");
> consumer.setMessageListener(messageListener);
> .....
> Before moving on to the C++ client question below, I have some queries of
> my own regarding the above.
> Are you planning to set unique correllationIds on every request message,
> and then create a new Session+Consumer (with selector) to listen for each
> reply? It somewhat seems this way from the above, and if so it is worth
> pointing out that this would be quite ineffecient. If on the other hand you
> were planning to create a single listener for some sort of per-consumer
> correlationID that was reused over time, this would be less inefficient but
> I would still have to wonder why you were using selectors to achieve this.
> Typically for request/response you would use replyTo on the requests in
> order to categorise which client receives the response by providering
> either a TemporaryQueue per client or fixed-name queue per-client, possibly
> using correlationId on top of that to achieve specific matching of
> particular requests and responses.
> Can you describe in more detail what you are trying to achieve?
But how can I do this with the C++ api ???
I don't have a full answer for this, so I am hoping someone with
familiarity of the C++ client can chime in here to expand on the partial
suggestions I do have:

In the JMS case, the Qpid client actually sends the selector string to the
Java broker at the subscription creation (using an argument key of
"x-filter-jms-selector" with value of the JMS selector string) and it
performs server-side selection, only sending messages to the subscription
which match its selector (with the C++ broker, the JMS client currently
performs the selection client-side). One possibility might be examining
whether the same subscription argument can be sent during consumer creation
with the C++ client, causing the broker to perform the selection for it.

Another possibility is that I know there has been work ongoing for the
0.22/0.24/beyond releases on the C++ side to allow message selection using
the C++ client and C++ broker, but I don't know specifics about this such
as whether it is all server-side or if client-side is also supported that
you could use against the Java broker (which doesn't currently support the
syntax which would be necessary for doing the equivalent server-side
matching, as I believe the arguments and/or syntax used on the recent work
for the C++ components is slightly different due to being based around a
registered extension for use with AMQP 1.0)


> Thanks a lot
> 2013/6/21 Xavier Millieret <xavier.millieret.info@gmail.com>
>> Thanks a lot Robbie, I will see all of this, monday, have a good week-end.
>> 2013/6/20 Robbie Gemmell <robbie.gemmell@gmail.com>
>>> Hi Xavier,
>>> There is some documentation about the updated configuration model here:
>>> http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-Java-Book/html/Java-Broker-Configuring-And-Managing.html
>>> In general the idea is that you should rarely need to edit the file
>>> yourself as much of the broker functionality is now configurable through
>>> the web managment UI so that you can configure it through a browser:
>>> http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-Java-Book/html/Java-Broker-Configuring-And-Managing-HTTP-Management.html
>>> I don't have a particular sample for using correlationId and JMSReplyTo,
>>> but you should be able to find some helpful examples on google since JMS is
>>> a vendor-neutral API. Essentialy, you would typically send a message to the
>>> request queue and setJMSReplyTo on it to another queue (often a
>>> TemporaryQueue each client creates for itself), and after processing the
>>> request the responder would send a message to the destination retrieved
>>> from the original request message using getJMSReplyTo after setting a
>>> correlation id on the response message that is typically the MessageID of
>>> the request mesage or some other application/request-specific value
>>> (perhaps included in the request as an alternative message header).
>>> (P.S it helps if you keep the mails on the user and/or dev mailing lists
>>> so others can see the replies or even respond themselves, which might have
>>> got you a quicker reply on this as I have actually been off ill :) )
>>> Robbie
>>> On 19 June 2013 13:01, Xavier Millieret <xavier.millieret.info@gmail.com
>>> > wrote:
>>>> Hi robbie,
>>>> I have a little question for you, please.
>>>> From the new release (0.22), the qpid configuration (config.json) has
>>>> changed, Do you have any documentation, sample about it ?
>>>> I want to implement request/reply pattern, and for this, must I playing
>>>> with correlationId, and setJMSReplyTo ? do you have any sample on it,
>>>> please.
>>>> Thank you for your help.
>>>> using qpid 0.22 and java client
>>>> best regards

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message