I guess it depends on you application design/requirements... one alternative approach would be to have a single (temporary) response queue per process, and then do response processing based on a correlation mapping on the client.
-- Rob On 26 June 2013 18:05, Xavier Millieret <[email protected]>wrote: > Yes, of course, but for the feature request / response, asynchronous mode, > you > must do it, right? Or I do not quite understand how to do this? > Is it better (a bridge for efficiency) using temporary queue to implement > the request/response without a selector as JMSCorrelationID? > > > 2013/6/26 Robbie Gemmell <[email protected]> > > > What you describe will of course work, it just means you are incurring > the > > significant overhead of creating a new consumer after every request as > > opposed to say using a long lived consumer with per consumer response > > queues and verifying the correlation IDs for your synchronous responses > > locally. If performance is of little concern to you then that is fine, I > > just wanted to ensure you were aware of the implications of using that > > approach. > > > > Robbie > > > > On 26 June 2013 16:12, Xavier Millieret <[email protected] > > >wrote: > > > > > I create a queue for any request and a queue for any reply (easier to > > > monitoring, and debuging, etc.) > > > When I want push a question, I send it in the requestQueue, a module > > takes > > > the request, doing something and post a reply on a replyQueue, the > > > requester want a response, but to be sure than the response is about > this > > > answer, I use the correlaionId like filter, I did before with activeMq, > > > Joram, and websphereMq, and this mechanism works fine, and from the JMS > > > point of view, it's a good practice ! So with qpid server and client > > (c++) > > > I wanted do the same > > > > > > > > > 2013/6/26 Robbie Gemmell <[email protected]> > > > > > > > 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 > > > > >>>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > > > > > >
