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;
_replySender.Send(replyMessage);
To reply back the message with previous sent correlation Id. 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).
On Mon, Jul 16, 2012 at 10:45 AM, Toralf Lund <toralf.l...@pgs.com> 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<g...@redhat.com> 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:
>>> users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org>
>>> For additional commands, e-mail: users-h...@qpid.apache.org
>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail:
>> users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org>
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>
>
> 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:
> users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org>
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
