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] > >
