On 17 December 2014 at 18:37, Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:
>
> On 17 December 2014 at 16:46, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> > 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?
> >
>
> No, and you shouldnt really use session.createQueue() either...but,
> its what lots of people do.
>
>
Yes, and looking at the JavaDoc it seems like it is indirectly implied but
not actually defined, that
Queue q2 = session.createQueue(q1.getQueueName());
should result in q1.equals(q2) returning true.
So, can you think of any case where prefix + some sort of exclusion
(prefix) pattern would not work? Depending on what makes a valid name in
the other systems you are aware of we could maybe even fix the black/white
list of addresses that do(n't) get prefixed. Certainly I think we'd want
to avoid prefixing anything that began / or $ ... but we might want to try
to restrict as many characters as possible if this doesn't interfere with
existing systems which need prefixing that we know about
> > 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".
> >
>
> That is one case I am thinking of. Destinations coming from JNDI
> rather than session.createQueue() being another, when the connection
> doesnt necessarily even exist, and isnt able to be referred to if it
> does. We could make destinations not created via
> session.createQueue(..) etc always require the full AMQP address
> string be provided of course, though then you might get some weirdness
> around getQueueName() behaviour between objects created via JNDI
> (which might not have access to f(x) or its reversal depending on how
> we define them) and those created e.g by a consumer (which would have
> access) after a message arrives.
>
>
I think I would argue that destinations from JNDI would either need the
"JMS" name and full AMQP address or the JMS name and f(X). Two different
JMS destinations which might both have JMS name "foo" but go through
different mangling functions shouldn't really be considered the same
address IMHO. In contrast on could potentially say that two AMQP global
addresses which share the same AMQP address do represent the same
destination "//example.com/foo".
> I have typically thought of 'provider specific' in the past to
> distinguish between different client+broker pairs, however we will
> have the same client potentially talking to multiple brokers at the
> same time as you mention, which is a little fuzzier for me. Its not
> clear to me that using a single client to do
> session.createQueue("foo") against one broker should give a
> destination object that isn't equal to one created by
> session.createQueue("foo") against another connection from the same
> client. Serializing the results from session.createQueue(..) in JNDI
> adds a further consideration, in that if I retrieve a previously
> stored output from one of those connections (or generate it some other
> way), should it be allowed to do something potentially unexpected if I
> later retrieve it and use it with the same client but a different
> connection than earlier?
>
>
As above I think JNDI will either need to be supplied with the AMQP address
(+ JMS name or demangler) or the JMS name and the mangling function.
> >
> >> 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:*"
> >
>
> Ah, I see.
>
>
-- Rob
