2008/10/1 Robert Godfrey <[EMAIL PROTECTED]>: > 2008/10/1 Gordon Sim <[EMAIL PROTECTED]>: >> Robert Godfrey wrote: >>> >>> 2008/9/30 Rajith Attapattu <[EMAIL PROTECTED]>: >>>> >>>> Hi Qpidians, >>>> >>>> Currently our temp queue naming is hard coded to "Temp_ " + uuid. >>>> We could change this to a format that is configurable and captures more >>>> useful information that can be utilized by, >>> >>> I think there are different point in here: >>> >>> 1) Should we change our temp queue naming to include more useful >>> information >>> >>> +1 from me >>> >>> 2) Should we add some sort of way for the client application to >>> configure the scheme for naming temporary queues created from JMS >>> >>> -1 From me (I have no problem with the low level API allowing any name >>> to be used) >> >> I tend to the opposite view! My 'theory' (vague as it is) is that it should >> be possible to use the JMS API but have flexibility in how those actions are >> 'mapped' into AMQP. (The name of the queue is interesting, but actually the >> exchange and binding details are in AMQP terms more valuable).
In general I agree... but I don't think that the *names* generated for temporary queues should be something that are relied upon... In particular for uniqueness you've pretty much got to put a UUID in there - so you shouldn't be able to let the clients get around that... And what purpose is there in configuring the *name* of the queue, other than to add informational stuff. >>> My fundamental objection to configurability is that the client >>> applications shouldn't need to know how these queues are named and >>> that allowing them to configure it is to risk them building in >>> dependencies on behaviour we may not be able to maintain in the face >>> of changes to the underlying AMQP model. >> >> I agree that the clients themselves most likely don't care and they should >> be able to work without any further thought. >> >> There may be reasons for adjusting the underlying system configuration >> though, and allowing for that seems reasonable to me. >> >> Obviously any configuration or code that relies on a particular aspect of >> AMQP becomes dependent on that aspect and at risk from alteration or removal >> of that aspect by subsequent revisions to the specification. >> >> At present I can create my own AMQDestination instance and that is usable >> from JMS clients for publishing to or consuming from. I may construct it to >> use a particular AMQP 'routing scheme'. By doing so I am becoming dependent >> on some aspects of the AMQP protocol. There is certainly risk there and we >> should advise carefully, but I don't think we should prevent that. >> I agree that we should give people that flexibility - but the Destination URL and the Connection URL are the places I would like to limit this to. Having more byzantine options for configuring behaviour will make things unmaintainable and lead to weird configuration dependencies in people's installations that will only cause issues when they come to upgrade. Limitting things to URLs whose format we can document in a single place and where we can clearly explain how they must change from one revision to another seems sensible to me. As an aside I don't consider choosing the *name* of the generated temporary queues to be part of the routing scheme. >> Allowing the strategy by which the AMQDestination constructed for a >> temporary queue is a further step along that path in my view. >> >> The alternative to configuration is to say either that a user cannot change >> how some of the more arbitrary decisions in the JMS client work or they have >> to write code to explicitly do what they want in AMQP terms (whether through >> Qpid extensions or another API). Moving this to configuration shields the >> application code from changes (which is still dependent on those features >> but should be easier to change for alternate deployments). >> >>> From a broker point of view we cannot depend on any naming scheme >>> since the names are client generated and thus non-Qpid clients may be >>> being used to connect to the broker (a use case for this functionality >>> as put to me involved being able to detect from the name that a >>> particular reply-to address related to a temporary queue). >>> What is the use case for a client being able to configure the naming >>> scheme? >> >> As above, I think that where there are reasonable choices in how JMS is >> mapped to AMQP, making that mapping customisable is in general valuable. >> >> However as a motivating example, I might want a 'federation' where the >> relaying of messages between brokers in that federation is controlled by the >> exchange to which they are published. >> >> Some clients may need to use a 'service queue' that I then want to be >> offered by another client on a remote node of the federation. So I want the >> queue used to communicate with that 'service' to be configured to use an >> exchange specifically setup for inter-broker routing, and in addition have >> the clients that use it have temporary queues that will work across the >> federation also. >> >> By picking the exchange name and binding key used I can configure my system >> to work in this federated manner without changing my client. >> But that requires you to have an intimate knowledge of exactly how your federation scheme (where your == Qpid C++ broker at this instance in time) works. Surely the use of reply-to addresses should be transparent to the sending client and the broker should handle any on-the wire translation to handle travelling through federation links. (Apologies if I am misunderstanding you here). Obviously the "correct" answer is for AMQP to handle global addressing. However setting "reply-to" on the JMS client should "just work" and you as an application programmer shouldn't need to worry about arcane details of the AMQP<->JMS mapping to get that working. -- Rob
