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<[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]
