On 17 October 2011 16:01, Rajith Attapattu <[email protected]> wrote:
> On Mon, Oct 17, 2011 at 5:54 AM, Robbie Gemmell
> <[email protected]> wrote:
>> Why do we resolve Address node types? This question arose during
>> review of proposed updates to the Address syntax implementation for
>> the Java client, but ultimately looks to be a wider question for all
>> the clients and so I am asking it here outwith that review.
>>
>> The documentation for the Address syntax on the Qpid and MRG websites
>> states that nodes can be specified as Queues or Topics, but that nodes
>> are Queues by default.
>
> Throughout my reply the word 'node' means Queues & Exchanges in 0-10 speak.
> The default applies when the node referred to by the address name does
> not exist and the client has received instructions to create it.
> (The documentation does have a lot of gaps and that's a all together a
> separate discussion :) ..)
>
The client should give the same default behaviour regardless of what
another user has done, so I dont think the above is correct behaviour.
Whether an exchange exists with that name should be irrelevant if
queues are the default. It also certainly isnt what the documentation
says:
"The node-type is one of:
topic: in the AMQP 0-10 mapping, a topic node defaults to the
topic exchange, x-declare may be used to specify other exchange types
queue: this is the default node-type"
>> It appears that the clients (at least the Java
>> one) instead ignore that statement and decide that if the user hasn't
>> specified a type then it should decide one for them, querying the
>> broker and figuring out whether there is a Queue or Exchange with the
>> node name and then picking Queue or Topic as the node type depending
>> on which exists (or throwing an exception if both do because the type
>> is ambiguous).
>
> In general applications should not be creating nodes (Queues &
> exchanges in 0-10 speak) in the broker.
That is odd, since the API supports it quite explicitly, more so now
than it ever did before. Seems like people can, will, and heavily do
use that feature, so we should probably take it into consideration
more fully.
> Therefore when an address is given, the client will attempt to verify
> the existence of the node referred by the address name.
> It also important to figure out what type of a node if the type is not
> explicitly specified.
The documentation says that the default is Queue, so why should we
bother to figure anything out? It seems entirely unreasonable that the
client can pick from different values (well, all the values, since
there are only 2 choices, Queue and Topic) if a node type is not
specified. Depending on what someone else might have done to the
broker, you could get a different answer each time, i.e it basically
doesnt have a default.
> This makes it easy for applications to specify addresses, as in most
> cases and address is simply a "name".
>
> The "type" is important as it helps to figure out if it's a Queue or a Topic.
> As the semantics differ based on the type.
That the type is important isnt in question, that we allow the client
to be in a position where we pick this for them (perhaps differently
than we did a previous time) is. We should pick a fixed default (as we
have documented), or make it a mandatory property and throw an
exception if it isnt present.
>
>> I would like to understand why this auto-resolving behaviour was
>> introduced. I believe that this needs to be removed from the Java
>> client entirely so that we can properly implement the Destination
>> hierarchy and provide an implementation to our users which actually
>> lets them use all of the JMS API easily. I would also argue it should
>> be removed from any of the other clients that are doing it due to the
>> behavioural ambiguities it seems to introduce.
>>
>>
>>
>>
>> For those wanting more of a read, here is some further elaboration to
>> the above (since the email got a lot longer than expected :D)
>
> Appreciate you taking the time to elaborate on your concerns. :)
>
>> In reviewing the proposed changes, Alex and I noted that it opened
>> possibility for creating Destination objects that don't implement
>> either the Topic or Queue interface, and instead use isTopic() and
>> isQueue() methods to check the answer against delegates which do
>> implement them. Rajith responded to our query on this that it was
>> because when creating an Address syntax based Destination from a
>> String, you cant tell what type of node it is until it is later
>> resolved against the broker.
>
> I think this was more of an issue with my implementation rather than a
> design issue with the addressing syntax in general.
>
> If we attempt to resolve the destination early, rather than when it's
> used to create a consumer or a producer we can solve this issue.
Not really, if you dont have a Connection when the destination is made
(eg JNDI lookup) then you certainly cant resolve anything.
> Lets look at the two cases where destinations are created/retrieved.
>
> 1. When creating queues/topics directly using the session.
> We need to resolve the address and verify the name supplied before the
> method returns.
> Ex ssn.createQueue(String name) & ssn.createTopic(String name)
>
> Currently my patch doesn't do that and if that is implemented then we
> guarantee that the Object returned is indeed representing a 'Queue' or
> a 'Topic' on the broker (not just implementing the jms interface).
>
This doesnt seem necessary or entirely reasonable given what the
createQueue method says it does (makes a queue representation object,
therefore no reoslution necessary as it isnt making a queue on the
broker and its definitely not a Topic)
> 2. Specifying addresses in the JNDI file.
> As you correctly pointed out this becomes an issue when we create
> destinations from the jndi file.
> As in this case when an application performs Destination dest =
> (Destination)ctx.lookup("my-dest"), we are unable to return a
> javax.jms.Topic or javax.jms.Queue implementation bcos we don't know
> the type unless explicitly specified.
>
> *** Perhaps this maybe the very reason why in JMS 1.1 they introduced
> the generic Destination interface.***
>
> Off the top of my head, I see two solutions to this.
>
> (a) . The users needs to explicitly specify the "type" when they
> specify addresses in the jndi file. And we use that to return a
> destination object that works specifically with the Queue or Topic
> interface.
This doesnt seem too unreasonable, however having a default node type
that is actually respected seems even more reasonable. Our docs
explicitly say that if type is not provided then node type is queue.
This seems like a sensible approach, so perhaps we should actually try
doing what the documentation says :)
> (b.1) Or not use the JMS 1.0 interfaces (which requires the
> specialized Queue or Topic interfaces) if a type is not specified.
> Obviously if they attempt to use a destination impl which
> simply implements the generic interface with the JMS 1.0 interfaces
> they would get a class cast exception.
> Please note The JMS 1.1 interfaces will work correctly with
> the generic Destination interface.
The Topic and Queue related parts of JMS 1.0 are still part of JMS 1.1.
Dropping of support for those interfaces is in no way a reasonable
solution to what is effectively an implementation issue with the
Address syntax.
> (b.2) Another solution would be something akin to the
> AMQAnyDestination (not a big fan of this). That is the
> AddressBasedDestination implements both the Topic & Queue interfaces
> allowing it to be passed into the JMS 1.0 interfaces and inside those
> method implementations we perform a check to see if they are indeed
> Queues or Topics by resolving an returning the correct
> AddressBasedTopic or AddressBasedQueue destination for the methods to
> work with.
That is indeed not a good aproach.
> There maybe more elegant solutions to this problem. I need to think a
> bit more here. But I'm sure we can come up with something better.
The best solution would appear to be stopping unecessarily querying
the broker to resolve destinations and always respect the user setting
(or lack thereof) for a node type.
>> This is troubling for various reasons, e.g. that it makes the code
>> uglier,
>
> This can be worked out. As I mentioned the proposed changes is the
> first step in a series of patches.
> I think we can do better with the code to make it less ugly and I'm
> experimenting to get there.
>
>> and then the slightly more pressing issue that it means it
>> wont be possible for users to use the majority of the JMS API with the
>> destinations they create from JNDI since many of the methods require
>> destinations which implement the Queue or Topic interface and not just
>> the super Destination interface.
>
> Again I'd like to draw your attention to the distinction between JMS
> 1.0 and JMS 1.1 interfaces.
> The JMS 1.1 interfaces will work very well with the generic
> javax.jms.Destinaitons.
>
> And by using the solution I outlined above we could ensure we provide
> the specialized interfaces required by the 'older' JMS 1.0 interfaces.
>
>> This behaviour seems highly undesirable to me, as in addition to the
>> design related issues discussed above that it provokes that sparked
>> the question, it simply seems unreasonable that we should be making
>> those decisions for the user (especially since we have documented that
>> we don't). This auto-resolution system also seems to open the
>> possibility of one users configuration unwittingly altering the
>> behaviour of another users application e.g. by creating an Exchange
>> with a given name later on, causing another users code to switch
>> without their consent from using Queues which might have been
>> auto-delete to using Topics, or by creating an Exchange where a Queue
>> with the same name already exists and causing another users client to
>> throw exceptions it didn't previously because the type can no longer
>> be auto-resolved. It also isn't clear how this is meant to interact
>> with the 'assert' functionality; surely we will sometimes be able to
>> pass an assertion for a decision we made, even if that isn't what the
>> user code used to be asserting against?
>>
>> Furthermore, it has been pointed out on the user list that this type
>> of querying can be a point of performance degradation, forcing (it
>> doesn't seem to be configurable?) the client to somewhat needlessly
>> round-trip to the broker in many cases it doesn't seem necessary.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:[email protected]
>>
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:[email protected]
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
