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.
> 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 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?
>
>> 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.
>
>> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
