On 11/29/2013 09:08 AM, Toralf Lund wrote:
Hi,
Just wondering, what gain is there in reusing Sender objects for the C++
Messaging API? I mean, over doing something like
qpid::messaging::Sender sender=session.createSender(address);
sender.send(message);
sender.close();
every time?
The biggest problem is that the createSender() is synchronous, and may
in some cases involve more than one request to the broker. That adds to
the latency of the response.
I'm thinking about this in conjunction with a request-response type
setup where the reply address is specified via message::getReplyTo(), so
it's not entirely obvious how long the senders should be kept, if at
all, but I do know that the same "reply-to" will generally be used
several times.
Any thoughts?
One option to reduce the number of distinct senders, and therefore
benefit more from caching, is to use a single a sender per exchange
(this is with AMQP 0-10) and just set the subject of the response
explicitly to match the required routing key.
The one issue here at present is that there is no way to create a sender
for the default exchange. That has been requested before (I can't find a
JIRA though) and it would perhaps be worth exploring. Ideally it would
be done in a way that would translate fairly naturally to 1.0 as well.
However, if you are able to control the types of reply-addresses you use
(e.g. amq.direct/# where # will be expanded to a uuid), then you could
cut down on the distinct number of senders needed, making caching more
likely to help.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
