Using a correlation-id is less overhead than working with a huge amount of queues. This will allow you to service a large number of request/replies with a relatively smaller number of queues.
You could probably experiment with both approaches and see for yourself. Rajith On Mon, Jul 16, 2012 at 9: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] >>> For additional commands, e-mail: [email protected] >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [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]
