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 14:47:09 GMT
On 29/11/13 14:00, Gordon Sim 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:
>>> 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?
>
> When creating the receiver for responses, use an address like e.g. 
> "amq.direct/#; {node:{type:topic}}",
That simple, eh? I somehow imagined that I had to explicitly set up 
bindings via e.g. x-bindings, and also carefully specify queue options, 
but if create a "response receiver" as in the example, I get a queue like

    amq.direct_029980d6-e626-423a-b09f-dc88e939eddc auto-del excl

with bindings (from qpid-config queues bind)

    Queue 'amq.direct_029980d6-e626-423a-b09f-dc88e939eddc'
         bind [amq.direct_029980d6-e626-423a-b09f-dc88e939eddc] => ''
         bind [241b5d96-d17f-4976-99ed-8d933ee031f2] => amq.direct


which is of course exactly what I want. One issue is that at least on my 
setup, you can't really use the shorthand suggested above as '#' won't 
be expanded when it's part of the subject (instead of the name), but 
that's a minor problem.

> then in the service, get the reply to address and rather than directly 
> creating a sender for it, create a sender for the name portion, e.g.:
>
>   const Address& address = request.getReplyTo();
>   if (address) {
>       Sender sender = session.getSender(address.getName());
>       Message response;
>       /* fill in response object*/
>       response.setSubject(address.getSubject());
>       sender.send(response);
>   }
>
Yep. That works.
> You can then combine that with caching of the senders, e.g. using the 
> approach suggested by Bruno. I've attached a patch to the current 
> client/server example that shows this working.
>
> What the use of the exchange in the reply-to does is allow you to use 
> fewer senders overall since many reply-to addresses can use the same 
> exchange, which may free you from worrying about when to close them.
Quite.


Thanks,


- Toralf



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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message