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: Sender name vs address (C++ messaging API)
Date Thu, 18 Aug 2011 06:55:21 GMT
Gordon Sim wrote:
> On 08/17/2011 07:44 AM, Toralf Lund wrote:
>> Gordon Sim wrote:
>>> On 08/16/2011 04:16 PM, Toralf Lund wrote:
>>>> The QPid "messaging" API will allow me to create a sender by address,
>>>> but (only) look up existing senders by name - the
>>>> qpid::messaging::Session class has:
>>>> Sender createSender(const Address &address);
>>>> Sender createSender(const std::string &address);
>>>> Sender getSender(const std::string &name);
>>>> Can I make *any* assumptions about the name given an address? Is there a
>>>> way to look up a sender created earlier for an address? Or isn't this
>>>> supposed to be possible? In that case, what exactly is getSender() for?
>>>> I mean, I'm assuming name is given by Sender::getName(), but requiring a
>>>> Sender to allow the lookup sort of defeats the purpose of the whole
>>>> method. OK, you can could maintain an address-to-name map, but then it's
>>>> probably easier to store the Sender objects.
>>>> It seems like the name is quite simply identical to the address if
>>>> something simple like a queue name was passed on create, but I suspect
>>>> it's not quite that simple for more complex addresses...
>>> At present the C++ client will use the address name as the name for
>>> the sender or receiver where it can do so without ambiguity.
>>> If you create two senders (or two receivers) for the same address,
>>> then the second will have a numeric suffix added to the name to
>>> distinguish them.
>>> So e.g.
>>> Sender s1 = ssn.createSender("my-node");
>>> Sender s2 = ssn.createSender("my-node/my-subject");
>>> would result in s1 having name 'my-node', but s2 having name 'my-node_2'.
>> OK.
>>> I would like to augment the logic to use the link name instead of the
>>> node name if explicitly specified in order to give more control where
>>> that is needed. Does that sound useful to you?
>> Uh, I must admit it is not entirely clear to me what a link name might
>> represent, but maybe...
> A 'link' is the logical association between a sender or receiver and 
> their target or source respectively. It a pathway along which messages 
> travel to or from some 'node'.
Well, yes, that's what I've read, and I understand all the words, but I 
have no idea of what it really means... Perhaps the problem is that 
talking about "links" and "nodes" is completely misplaced in the context 
of AMQP, IMO. To me a link between nodes is something like a direct 
socket connection between applications running on two different 
computers, which is precisely what I'm trying to avoid by using AMQP. 
But that's a different discussion, of course... (And I know, the terms 
are from the AMQP crowd, not QPid developers.)

>> What I'm looking for is a clear and consistent
>> way to distinguish senders in a case rather your example above, only I'd
>> use something more like:
>> Sender s1 = ssn.createSender("my-node/my-subject");
>> Sender s2 = ssn.createSender("my-node/some-other-subject");
>> using 'my-node' and 'my-node_2' for addressing might work, but is
>> obviously not ideal. Specifying an additional id of some kind would
>> probably be OK.
> My initial thought was to use the link name. However on reflection that 
> isn't really ideal either.
> What you really want is a way to give the senders a name of your own 
> choosing *independent* of the address used (likewise for receivers).
> So either an overloaded createSender()/createReceiver() method that 
> additionally took a name to use and/or a Sender::setName() to alter the 
> name once you have created the sender. I think I prefer the former.
I agree.

- Toralf

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.

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message