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: Reusing messaging::Sender vs creating every time
Date Fri, 29 Nov 2013 11:17:57 GMT
On 29/11/13 11:19, Gordon Sim wrote:
> 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.
That could be a bit of an issue.

>
>> 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.
Right.

It's not entirely clear to me how that might be done, though. I mean, 
the reply address is just a queue - there is no explicit binding or 
anything.

>
> 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.
Yes. Maybe this is what I'd need for the "simple queue" address?

>
> 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),

Yep. I'm still at a stage where I can easily change the addressing scheme.

So, in this setup, I'd use the "#" bit as subject?

- Toralf


> then you could cut down on the distinct number of senders needed, 
> making caching more likely to help.
>
>
> ---------------------------------------------------------------------
> 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