You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Toralf Lund <to...@pgs.com> on 2012/07/16 13:34:56 UTC
Overhead of creating (private reply) queue?
Hi.
What kind of overhead to you expect from having to create the
("private") queue when initialising a qpid::messaging::receiver?
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?
- Toralf
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
Re: Overhead of creating (private reply) queue?
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jul 17, 2012 at 5:56 AM, Toralf Lund <to...@pgs.com> 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<to...@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<gs...@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<us...@qpid.apache.org>
>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>
>>>> ---------
>>>> To unsubscribe, e-mail:
>>>> users-unsubscribe@qpid.apache.**org<us...@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<us...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Overhead of creating (private reply) queue?
Posted by Toralf Lund <to...@pgs.com>.
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...
> _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?
> 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.
Thanks,
- Toralf
>
>
> On Mon, Jul 16, 2012 at 10:45 AM, Toralf Lund<to...@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<gs...@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<us...@qpid.apache.org>
>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>
>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@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<us...@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
Re: Overhead of creating (private reply) queue?
Posted by Virgilio Fornazin <vi...@gmail.com>.
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 <to...@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<gs...@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<us...@qpid.apache.org>
>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@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<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Overhead of creating (private reply) queue?
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <to...@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<gs...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Overhead of creating (private reply) queue?
Posted by Toralf Lund <to...@pgs.com>.
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<gs...@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
Re: Overhead of creating (private reply) queue?
Posted by Rajith Attapattu <ra...@gmail.com>.
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.
Regards,
Rajith
On Mon, Jul 16, 2012 at 8:39 AM, Gordon Sim <gs...@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
Re: Overhead of creating (private reply) queue?
Posted by Gordon Sim <gs...@redhat.com>.
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