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 12:29:20 GMT
On 29/11/13 12:48, Bruno Matos wrote:
> On 11/29/2013 11:17 AM, Toralf Lund wrote:
>> 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.
[ ... ] I was having the same problem, and someone (sorry for not 
remember who) suggested this, that helped:
>     bool create = false;
>     Sender sender;
>     try {
>       sender = session_.getSender(queue);
>     } catch (KeyError& e) {
>       create = true;
>     }
>     if (create) {
>       sender = session_.createSender(queue);
>     }
> The session may already have the sender for the queue, so you just 
> reuse it.
Well, actually, I've been thinking along those lines, already.

The problem is, that way the senders will never go away, and there will 
come a time where they aren't going to be needed as the queues could 
come and go even though each one is generally used several times. And 
there will be more new senders over time, too, so that everything will 
keep building up - which is not very nice.

Now, if I could find a way to tell that a sender is not going to be use 
any more because its queue has in fact gone away, I could just clean up 
at intervals, but I know of no way of doing that. In fact, there doesn't 
even seem to be a direct way to ask what senders actually exist. I could 
of course try to keep track of what senders I've created and when they 
where used "on the outside", and close the least-recently accessed ones 
from time to time  - but this might easily get cumbersome, and an 
address can in fact still be valid even if it's a long time since it was 
used last.

- Toralf

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

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

View raw message