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 <[email protected]>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, > Session.AUTO_ACKNOWLEDGE); > 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) Robbie > > Thanks a lot > > > 2013/6/21 Xavier Millieret <[email protected]> > >> Thanks a lot Robbie, I will see all of this, monday, have a good week-end. >> >> >> 2013/6/20 Robbie Gemmell <[email protected]> >> >>> 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 <[email protected] >>> > 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 >>>> >>> >>> >> >
