On 17 December 2014 at 17:25, Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:
>
> On 17 December 2014 at 15:00, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> > On 17 December 2014 at 15:45, Robbie Gemmell <robbie.gemm...@gmail.com>
> > wrote:
> >>
> >> On 17 December 2014 at 13:43, Rob Godfrey <rob.j.godf...@gmail.com>
> wrote:
> >> > On 17 December 2014 at 13:37, Robbie Gemmell <
> robbie.gemm...@gmail.com>
> >> > wrote:
> >> >>
>
>
[.. snip ..]
> >>
> >> Any more concrete thoughts/examples?
> >>
> >>
> > Nothing concrete... more just wanting to avoid premature
> "standardisation"
> > on something we later find to be inadequate for the eventual requirement.
>
> Ok. I'm trying to figure out if I am on the same page. Are you
> thinking of something that would simply be used to decide whether a
> given fixed/supplied prefix was used or not (e.g apply this
> fixed/given prefix if this regex matched anything in the given JMS
> 'name' string), or something more complicated that might decide what
> to apply based on what matched?
>
>
It may be that it is sufficient to say prefix + exclusion pattern, e.g.
prefix with "queue:" unless the name begins with $ or / - that would
probably cover all the cases I can currently think of (global addressing
and magic $ addresses)
> > Another consideration might be special addresses, like "$management"
> which
> > the server would not want to be mangled but which we would still want to
> > make easily accessible through session.createQueue().
> >
>
> Good point.
>
> >
> >> >
> >> >
> >> >
> >> >> Thoughts?
> >> >>
> >> >>
> >> >
> >> > A quick thought on Destination equivalence - I'm guessing that in JMS
> >> > terms two Destinations are equal iff they are of the same type
> >> > (Topic/Queue/etc - derived from meta-data) and use the same *mangled*
> >> > AMQP address?
> >> >
> >> > -- Rob
> >> >
> >>
> >> If the name mangling is conducted on the way out of the client to form
> >> an AMQP address from the initial 'JMS name', and reversed on the way
> >> in to the client to give the 'JMS name' used for
> >> getJMSDestination/getJMSReplyTo, then I guess two Destination objects
> >> would be considered equal if they had the same type and same 'JMS
> >> Name'.
> >>
> >>
> > I was thinking that we would potentially want to avoid having to have a
> > "reversible" mangling algorithm. IIRC you can't extract the name from a
> > Destination object after it has been created.
>
> I dont think we can get away without reversability.
>
> All the concrete Destination objects JMS specifies let you retrieve
> the name, via getQueueName() or getTopicName(). Thats how you figure
> out where the message was sent or should be returned to if you use
> getJMSDestination()/getJMSReplyTo().
>
I forgot about getQueueName() / getTopicName() but you shouldn't be using
them for anything if you are looking for portability should you?
However I do take your point that you would potential want to have a
demangling function so that getQueueName() could be computed from the AMQP
address.
>
> > the AMQP address is the
> > "real" identity as far as AMQP is concerned. Moreover there may be some
> > addresses (even within systems which have distinct queue and topic
> domains)
> > which exist within other domains, or which live outside the domains
> > ("$management" for example)
>
> Sure, but the JMS objects wont necessarily know about the exact AMQP
> address unless we always make the application provide the full AMQP
> address or decide on a single fixed prefix that can be applied/removed
> within the destination objects themselves.
>
>
Huh? If you have a name mangling function that turns X -> f(X) (where f(X)
is the AMQP address) then createQueue( X ) can know f(X) and messages that
come from the wire are going to be aware of f(X) (the AMQP address) since
that is what they are built from. You shouldn't need to know the "JMS"
name in order to test equality. When do you think that the JMS objects
would not know (be able to calculate) the AMQP address? The only funkiness
might be if you were bridging between two JMS over AMQP connections where
the prefix in use on the different connections was different. In that case
I'm not sure that two addresses can ever be considered "equal".
> Special addresses like $management might really live outside the
> domains, but the client is ultimately going to access them via the
> domains, e.g session.createQueue("$management") from your example
>
I was using "domain" to mean a "namespace" within the AMQP address space.
"$management" does not live within "queue:*" or "topic:*"
> earlier, which will give a JMS object that gets compared like any
> other unless the client is made specifically aware of those special
> addresses in some way.
>
-- Rob
>
> >
> > -- Rob
> >
> >
> >> >
> >> >
> >> >> Robbie
> >> >>
> >> >>
> >> >>
> >> >> Additional Context:
> >> >>
> >> >> We also need to transmit the destination type information during link
> >> >> (e.g producer/consumer) attachment and on sent messages to ensure we
> >> >> can support the required JMS behaviours (e.g. to indicate we are
> >> >> attaching to a particular type of node, say a queue, and for carrying
> >> >> JMSDestination and JMSReplyTo type on messages to indicate/discover
> >> >> where a message was sent).
> >> >>
> >> >> For handling these points we are defining the following behaviour:
> >> >>
> >> >> # During link attachment for producers/consumers:
> >> >> - Node name carried in source/target "address" field string.
> >> >> - JMS Destination type represented by capabilities on the
> >> >> source/target (e.g "queue", "topic", "temporary-queue",
> >> >> "temporary-topic").
> >> >> - Clients can optionally assert on the attach response that the
> >> >> required capabilities exist in the source/target to ensure they have
> >> >> attached to a node that meets their requirements.
> >> >> - 'Broker' peers can use the capabilities to determine the type of
> >> >> node to create if it is a dynamic node being requested (or if they
> >> >> support auto-creation of non-temporary nodes).
> >> >>
> >> >> # When sending messages:
> >> >> - Node names carried in "to" and "reply-to" fields as appropriate.
> >> >> - JMS Destination type carried in "x-opt-jms-dest" and
> >> >> "x-opt-jms-reply-to" message annotations as a byte.
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> >> >> For additional commands, e-mail: users-h...@qpid.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> >> For additional commands, e-mail: users-h...@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
