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:[email protected]
