qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toralf Lund <toralf.l...@pgs.com>
Subject Re: Overhead of creating (private reply) queue?
Date Mon, 16 Jul 2012 13:45:25 GMT
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<gsim@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
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@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
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message