Hi Roger, I have now committed some changes to trunk for https://issues.apache.org/jira/browse/QPID-4261 , adding some options ('exchangedurable', 'exchangeautodelete', and 'exchangeinternal') to the BindingURLs which should hopefully now let you set the properties used in the ExchangeDeclares to match the exchanges present on your RabbitMQ broker. Could you try them out and let me know how you get on? I forced the nightly trunk build job to run early so you can get a copy of the updated client here now if you need: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Artefact-Release/lastSuccessfulBuild/artifact/trunk/qpid/java/client/release/
I doubt the diff will apply automatically to 0.18 (now available via http://qpid.apache.org/download.html ) due to interaction with the earlier changes from QPID-4250 (which probably also wont apply automatically either), but I expect the fixups required should be absolutely trivial. I'm not sure how much conflict there will be if you try applying it to 0.16, but we can work that out if need be. Robbie On 29 August 2012 00:00, Robbie Gemmell <[email protected]> wrote: > On 27 August 2012 20:39, Roger <[email protected]> wrote: > >> > If disabling the queue and exchange declares is >> > an option for you (i.e you can rely on them being present already) then >> > you >> > should be able to use that change along with the system properties I >> > mentioned to do so. If not, we can try to work out a suitable course to >> > allow manipulating the exchange declare properties. >> >> We are running a mixed bag here. Some queues are predefined, while others >> (actually system named topics) are temporary and defined on the fly. >> Consequently, the proposed solution doesn't address all our use cases. >> I find it odd that qpid.declare_exchanges is a global parameter as it >> implies an all-or-none configuration approach. > > > Ok. I only brought it up because I spotted them while looking into what > you were seeing and wondered if it would work since you had mentioned using > predefined destinations. The properties arent really documented or even > intended for regular use I believe, but someone obviously had a use case at > some point and added them. > > >> Most, if not all, my >> experience in messaging systems have always leveraged on-the-fly >> queue/topic >> creation. > > > On-the-fly queue and topic creation is supported and indeed fairly usual, > the problem is your custom exchanges are not something the Qpid JMS client > handles well since it historically hasn't catered for that (mainly sticking > to the pre-existing amq. exchanges) and has never saw much/any use of where > 0-8/0-9/0-9-1 + BindingURLs are concerned. The newer 'Address' syntax > supported by the AMQP 0-10 path of the client handles this much better, but > obviously that doenst do much good when using the client with AMQP 0-9-1 > since that requires the use of BindingURLs. > > >> Would it not be worthwhile having a plane property object with >> these properties that can be passed to the method? Defaults values, >> possibly >> based on system env values, could be set on object creation and reset. >> Additional methods without the property object could also be provided >> where >> system defaults are assumed. >> >> > The issue is not really how the values gets (in)to the method, but where > the exchange property values actually come from. The changes you have > mentioned so far involved repurposing the existing options intended for the > queue (the BindingURL syntax doesnt define a way of setting exchange > properties, which is presumably why the values were hard coded in the > declares), which doesn't really work since it prevents various combinations > such as differing durability for a queue and exchange, and would also > change the clients behaviour for all the existing users. > > I have raised a JIRA ( https://issues.apache.org/jira/browse/QPID-4261 ) > to extend the BindingURL sytax to provide options for the exchanges which > can then be used via the (AMQ)Destination object (in similar fashion to the > queue options) when sending the ExchangeDeclare commands during > consumer/producer creation. I have done some of the work already but it > could be a few days before I get enough time in the evening to finish it. I > have attached a couple of work-in-progress patches to the JIRA which you > can have a look at to see where im going with it. > > >> >> Concerning your comments on the 'noWait' issue. I was concerned that while >> my changes did solve my 0-9-1 issues, it might create regression issues >> and >> break the same use case running against a broker operating a different amq >> version. It appears that you are in a similar boat. So am I out of luck >> here >> and should simply run with my local modifications? I'm caught in a hard >> spot >> here as our objective is transparent JMS and AMQ regardless of version. >> >> > What I was trying to get at with my comments is that I think the > abstraction of the clients 0-8/0-9/0-9-1 and 0-10 protocol implementations > in that area isnt particularly pretty at all, but it doesnt appear to be > the cause of any issue. The 0-8/0-9/0-9-1 and 0-10 paths of the client do > treat that value differently becaues the protocol actually is different in > that area, and the historic behaviour of the client for 0-8/0-9/0-9-1 users > was retained when the 0-10 support was added. As such it seems likely that > the changes you made actually caused the issue you saw. > > The (hard coded) values used for noWait in the queue/exchange declare > commands in the 0-8/0-9/0-9-1 path are appropriate to what the various > areas of code are trying to do and I believe should remain as-is, so > possible explanations for the problem would seem to be either that your > changes resulted in an inappropriate combination (a declare command with > noWait=true being sent by a section of code that expected/required it to be > false, resulting in the client waiting for a response it had just > explicitly asked the broker never to send), or that the RabbitMQ broker has > a bug. In this particular scenario the latter seems unlikely, which > suggests the first option. > > I dont see any need to change the noWait handling here, the main issue for > you is being able to set the exchange properties (auto-delete, > durable...probably not internal, I'd have to wonder about creating > 'internal' exchanges with a client given that the point is they are > 'internal wiring') so that the brokers validation of the incoming exchange > declare matches the properties found on the pre existing exchange, which we > will get done via the JIRA mentioned above. > > Robbie > >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://qpid.2158936.n2.nabble.com/Hard-coded-destination-parameters-prevent-creation-of-Producer-and-Consumer-tp7581160p7581325.html >> Sent from the Apache Qpid users mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
