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. 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). 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) 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. This is troubling for various reasons, e.g. that it makes the code uglier, 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. 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]
