On 17 December 2014 at 17:59, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> 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
>
Right now I'm not sure I can. I am currently aware of systems that
need or might want prefixes that dont begin with / or $. The systems I
am aware of that use "/" as the first character in their addresses
would likely need to keep using those full address in
session.createQueue(..) etc to continue supporting all the behaviours
they have defined, and so they might not want prefixing anyway.
Finally, I am aware of yet other systems with addresses that dont
begin $ or / and but which wouldnt want any prefixes as they would
interfere with the changable ones they already have.
One thought I had after writing the above is management addresses
where the node name doesnt begin (but might end?) with $management.
Wasnt that an idea at some point?
With the use of / to exclude potential future global address syntax
from any prefixing, would we then be saying that for such global
addresses the application+broker will have had to figure out this
'queues and topics with the same name' issue by themselves? In some
cases at least it seems like essentially the same problem we are
currently discussing, just with a more complicated value going in
session.createQueue(..) etc. Feels a little weird handling one but not
the other.
>
>
>> > 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).
That sounds like a fun sytax :)
> 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.
I guess it depends when the name goes through any mangling. I think I
have been thinking of it happening later than you are, such that using
either of those "foo" destination objects with any particular
connection would end up with the message going to the same place when
using that connection, in which case treating them as equal seems
fine.
If we apply the mangling earlier, then using different destination
objects with the same JMS name on any particular connection may result
in messages going different places via that connection (or as likely,
failing to be delivered entirely), in which case yes treating them as
equal would seem odd, but to me so is that result if they start with
the same JMS name.
> 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".
>
Agreeed (assuming they have the same type of course).
>
>> 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.
>
I worry that is making things a bit complicated, with JNDI usage
potentially doing one thing and session.createQueue usage doing
another and users needing to line them up. It feels like it would be
introducing a new way for users to trip themselves up while still
requiring them to configure the same information I started out hoping
we could avoid, just in a different way/place.
I think its possibly even preferable the way it has been implemented
previously where the JNDI and session.createQueue strings are the
same, and either the Connection[Factory] knows about the prefixes, or
the full AMQP address has to be used in both JNDI and
session.createQueue(..). We could simply add the name
white/blacklisting idea to that. Though that doesnt solve the 'queues
and topics with same name' issue unless you actually set a prefix.
>
>> >
>> >> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
