Hi Roger, I have put a fix in via https://issues.apache.org/jira/browse/QPID-4250 for the issue I noticed with regards to the exchange declares failing to be inhibited by qpid.declare_exchanges=false when creating producers on 0-8/0-9/0-9-1 connnections. 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.
I also took a look at some of the code you have mentioned making changes to and now have a better idea of what happened that caused the 'hang' you seeing as a result. The 'nowait' property of the exchangeDeclare controls whether the broker replies to the clients command, and by making the changes you talked of you ended up with areas of the client code doing a 'syncWrite' call with an exchangeDeclare command that had noWait=true, thus indicating the client wasnt waiting for a reply (so the broker then didnt reply as a result) when it actually was and so it would just sit waiting for a reply until it eventually timing out. If the exchangeDeclare sets noWait=true then the code writing the frame would need to do a 'non sync' write call instead (which is what the client does when performing the exchange declare during producer creation, because the messages being produced have to follow that and will validate the result of the operation implicitly). The 'noWait' parameters to some of the methods these commands are being sent in are actually shared between the clients somewhat distinct 0-8/0-9/0-9-1 and 0-10 code paths and are sometimes only actually used by one or the other. More confusingly still, its possible some of the noWait parameters in those methods/classes may actually be leftovers from when the client had an asynchronous I/O layer and so some may have nothing to do with the queue/exchange declare attribute at all. It could defintiely use a tidy up and possibly comments where some non-obvious things are happening. Robbie On 24 August 2012 16:59, Robbie Gemmell <[email protected]> wrote: > Hi Roger, > > As I mentioned, some of these issues are purely down to historic behaviour > and typical usage model of the Qpid JMS client (e.g I deal with a lot of > users, and genuinely not one of them uses custom exchanges) and your now > trying to use it in situations it doesnt cater particularly well to as a > result. The Binding URL format was never intended to convey some of the > information you are now trying to, so I'd be wary of making some of the > changes in exactly the manner outlined so far as it would impact behaviour > for lots of people using the client already, however I'm sure there are > other ways we could achieve similar results whislt allowing retention of > historic behaviour and adding the option to configure it for your needs. > > That said, most of the problems you are seeing and trying to work around > look to relate to exchange and queue declares it would seem you might not > actually need to be performed. You mentioned wanting to use pre-existing > durable entities on your RabbitMQ broker. If so, do you actually need the > client to declare anything for you, or can it just rely on their existence? > If you can, there are system properties (qpid.declare_queues and > qpid.declare_exchanges, defined near the top of AMQSession) that can be set > to false to disable the exchange and queue declares the client does under > the covers to hide such technicalities from users of its JMS API. I do > notice there appears to be a gap in their usage though, where the > 0-8/0-9/0-9-1 producer creation can still do an exchange declare in > BasicMessageProducer_0_8#declareDestination, thats a bug I'll fix at the > weekend. > > Robbie > > > On 23 August 2012 21:41, Roger <[email protected]> wrote: > >> > >> > When I changed the code to use the destination values, it successfully >> > created the producer. I can now send messages. >> > With respect to the consumer, the ExchangeDeclareBody was successfully >> > created, but the system hangs on protocolHandler.syncWrite. Digging into >> > that now. >> > >> >> The only usual reason for it to wait there is that it didn't get the reply >> frame it was waiting for, posibly because something on the other end went >> bang. Did you get any further digging into it? >> >> I managed to resolve the hang issue. Did so by diffing communications of a >> rabbitmq and qpid consumer. The hard-coded nowait is set to true in >> createExchangeDeclareBody. It appears that it can have either value when >> creating a producer, but should be false when creating a consumer. Not >> stating that this is necessarily correct - being knew to AMQP - but that >> is >> what makes the code work. >> >> These aforementioned discoveries lend themselves to concern. >> I've now modified the code to accommodate the hard-coded durable and >> autodelete values, and have changed nowait to false. Are these valid >> changes? Should the nowait be made variable for producers? Should >> internal, >> and for that matter arguements (FieldTable), be made variable? >> How do we get these changes into the next version? Bug? >> >> On the other hand, if these changes are not valid what is the proper usage >> so that I can communicate with Rabbitmq. >> >> Roger >> >> >> >> >> -- >> View this message in context: >> http://qpid.2158936.n2.nabble.com/Hard-coded-destination-parameters-prevent-creation-of-Producer-and-Consumer-tp7581160p7581249.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] >> >> >
