On Tue, Jul 17, 2012 at 5:56 AM, Toralf Lund <[email protected]> wrote: > On 16/07/12 16:12, Virgilio Fornazin wrote: >> >> We used here to create a private reply queue for each request/reply (and >> also, we discovered leaks with Ted Ross in 0.10 version that time). >> After that, we changed our code to pre-create a private reply queue for >> each connection that perform request / reply operations, using message. >> >> message.ReplyTo = ... >> message.CorrelationId = correlationId; >> >> sender.Send(message); >> >> In the reply side, we put: >> >> replyMessage.Subject = _message.ReplyTo.Name; >> replyMessage.CorrelationId = _message.CorrelationId; > > OK. So you set up the request and response to have the same correlation id. > As opposed to setting the correlation id of the response to the *message* id > of the request. I've been wondering which is the most proper use...
In my experience the most common scenario is what Virgilio described. The request sets a correlation-id and the response using the same. > >> _replySender.Send(replyMessage); > > >> To reply back the message with previous sent correlation Id. > > Fair enough. What exactly do you do if you get a message with the "wrong" > correlation id? Receive it the normal way, but just don't handle it? Call > session::reject()? Call session::release()? Just refrain from calling > session::acknowledge()? Something else entirely? If it does happen, it suggests that there is a bug in the program. The process that sets the correlation-id and the reply-to queue should make sure they match. The "replies" that end up in a particular reply-to queue should be the correct messages. i.e The consumers that process the reply-to queue should know how to process those replies (messages). However in case it happens (a bug IMO), (*) If there is one and only one consume on the reply-to-queue, then "rejecting" the message seems reasonable. (*) If there are more than one consumer then you could "release" the message, hoping another consumers on the queue would know how to process it. > >> This make >> things faster and also, lowered the latency since we don't need to setup a >> queue in the broker, >> avoid resource usage and network round-trips (this helps a lot in >> high-latency connections). > > Yeah, I definitely worry most about the latency related to queue setup. I > mean, I don't believe the resource usage at any given time will be higher > with queues created on demand. In fact, it may be lower, as response queues > will only exist while clients are waiting for replies. This is assuming the number of queues in both cases are the same :) > > Thanks, > > - Toralf > > > >> >> >> On Mon, Jul 16, 2012 at 10:45 AM, Toralf Lund<[email protected]> wrote: >> >>> On 16/07/12 15:01, Rajith Attapattu wrote: >>> >>>> I'd agree with Gordon. >>>> If at all possible I will pre-create my private queues, rather than >>>> creating them on demand. >>>> Writing a bit of extra code for working with a fix number of queues is >>>> worth from a performance standpoint. >>>> >>> It's not just about handling the queues, though. If I reuse the response >>> queue, I also have to worry about responses that actually belong to >>> requests sent in the past. A simplistic way of handling those would be to >>> just clear the queue before a new request is sent, but there is a risk >>> that >>> the remote end sends a reply that I've given up on after the queue is >>> cleared, but before the new request is processed. So, to make sure I >>> always >>> read the correct reply, I probably have to add/match extra id fields - >>> possibly "messageId"/"correlationId". This also represents *some* >>> overhead... >>> >>> - Toralf >>> >>> >>>> Regards, >>>> >>>> Rajith >>>> >>>> On Mon, Jul 16, 2012 at 8:39 AM, Gordon Sim<[email protected]> wrote: >>>> >>>>> On 07/16/2012 12:34 PM, Toralf Lund wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> What kind of overhead to you expect from having to create the >>>>>> ("private") queue when initialising a qpid::messaging::receiver? >>>>>> >>>>> If it is not a durable queue then the overhead is not that high, >>>>> however... >>>>> >>>>> >>>>> I'm implementing request-response type communication over a direct >>>>>> >>>>>> exchange, with a private "auto-delete" queue for responses (whose >>>>>> address is specified in replyTo on the request message.) So far, I've >>>>>> just created a new queue on every call rather than trying to keep the >>>>>> same one throughout the session because it's simpler in many ways - it >>>>>> saves me from some queue management, and I don't have to worry about >>>>>> reading the wrong response e.g. because of a time-out waiting for a >>>>>> reply to a previous request. >>>>>> >>>>>> So, do you think that this sounds like a bad idea, or is it quite all >>>>>> right because the overhead imposed by creating and deleting queues all >>>>>> the time is negligible? >>>>>> >>>>> ... this probably depends on the expected/required rate of requests. >>>>> >>>>> For low rates (say 100s or perhaps 1000s per second) it probably >>>>> wouldn't >>>>> have too much impact, but as you start getting above that then you >>>>> would >>>>> be >>>>> spending time on queue creation and deletion that would be better spent >>>>> processing messages and requests. >>>>> >>>>> >>>>> >>>>> ------------------------------**------------------------------** >>>>> --------- >>>>> To unsubscribe, e-mail: >>>>> [email protected].**org<[email protected]> >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> ------------------------------**------------------------------** >>>> >>>> --------- >>>> To unsubscribe, e-mail: >>>> [email protected].**org<[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> This e-mail, including any attachments and response string, may contain >>> proprietary information which is confidential and may be legally >>> privileged. It is for the intended recipient only. If you are not the >>> intended recipient or transmission error has misdirected this e-mail, >>> please notify the author by return e-mail and delete this message and any >>> attachment immediately. If you are not the intended recipient you must >>> not >>> use, disclose, distribute, forward, copy, print or rely on this e-mail in >>> any way except as permitted by the author. >>> >>> ------------------------------**------------------------------**--------- >>> To unsubscribe, e-mail: >>> [email protected].**org<[email protected]> >>> For additional commands, e-mail: [email protected] >>> >>> > > > This e-mail, including any attachments and response string, may contain > proprietary information which is confidential and may be legally privileged. > It is for the intended recipient only. If you are not the intended recipient > or transmission error has misdirected this e-mail, please notify the author > by return e-mail and delete this message and any attachment immediately. If > you are not the intended recipient you must not use, disclose, distribute, > forward, copy, print or rely on this e-mail in any way except as permitted > by the author. > > --------------------------------------------------------------------- > 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]
