Thanks for the help, Rob. Here's some more feedback from today's experiments. I tried the setDeliveryMode on my 'basic' producer client (AMQP 1.0 client interacting only with ActiveMQ 5.9.0 broker's AMQP transport connector). In so doing, I could use the Qpid 0.27 AMQP 1.0 API to send() without hanging. A basic consumer client retrieved the message without issue. * BTW, I also retried the basic test (without the setDeliveryMode call) with Qpid 0.26 AMQP 1.0 API and DIDN'T get the hanging. Results from testing 0.27 with my "consume/receive msg via Openwire context/session, then produce/send same (untouched) msg via AMQP 1.0 context/session" test - both interacting with same (machine-local) ActiveMQ 5.9.0 broker: 1) WITHOUT using setDeliveryMode() call on producer, I get this stack trace (error during producer's send call): javax.jms.JMSException: Link was detached at org.apache.qpid.amqp_1_0.jms.impl.MessageProducerImpl$DispositionAction.wasAccepted(MessageProducerImpl.java:519) at org.apache.qpid.amqp_1_0.jms.impl.MessageProducerImpl.send(MessageProducerImpl.java:331) at org.apache.qpid.amqp_1_0.jms.impl.MessageProducerImpl.send(MessageProducerImpl.java:238) at Listener.main(Listener.java:85) 2) WITH using setDeliveryMode() call on producer, I get: No exception raised, however after send() returns, there is NO message in the target Q (Q2). and Finally, just to add to the total confusion... Same consume-then-produce test, only this time consume/receive is from ActiveMQ 5.9.0 broker, send() goes to separate (but same local host) Qpid 0.14 broker destination (using AMQP 0-10 client API from 0.24, since this broker doesn't yet support 1.0): No exception raised, message goes into Qpid broker (and subsequently retrieved by a basic consumer client) without issue. ??!! Quite confused now... Mark.
Sent from my iPhone > On Feb 20, 2014, at 3:16, Rob Godfrey wrote: > > The most likely candidate for a change in behaviour would seem to be > https://issues.apache.org/jira/browse/QPID-5455, which means that 0.26 and > 0.27 enforce synchronous publishing semantics. I know this has been tested > against ActiveMQ 5.9.0 but perhaps if you are using an earlier version it > may expose issues in their handling of synchronous publish requests. > > To test if this is the issue you could change your test code to use > non-persistent delivery ( > messageProducer.setDeliveryMode(DeliveryMode.NON_PERSISTENT), or use > messageProducer.send(msg, DeliveryMode.NON_PERSISTENT, > Message.DEFAULT_PRIORITY, Message.DEFAULT_TIME_TO_LIVE) ). > > -- Rob > > >> On 20 February 2014 10:48, Rob Godfrey wrote: >> >> Hmmm, I can't imagine this change would have had that effect... I'll have >> a look back through the changes in the client between 0.24 and 0.26 to see >> if there is anything obvious... Can you confirm which version of ActiveMQ >> you are using? >> >> Thanks, >> Rob >> >> >>> On 20 February 2014 05:42, Mark Barker wrote: >>> >>> Thanks Rob & Robbie. That's quick stuff. >>> >>> I did manage to do an ant build (was all a bit fingers-crossed, since I'd >>> never even touched subversion before - but it seemed to work), but it was >>> good to have the build from the experts to have to try too! >>> >>> I will need to do some more testing tomorrow, but one thing I did notice >>> so far is that in a basic test case (just a single-protocol, single >>> context/session AMQP 1.0 JMS client producer), the client seems to hang on >>> the producer.send() call with this 0.27 client (with the ActiveMQ broker on >>> its AMQP transport connector). The message has indeed been placed in the >>> queue nominated on the broker, since if I CTRL-C out of the producer client >>> and run a simple consumer client (again linked against the new 0.27 API >>> test .jar), the message is subsequently received seemingly intact (at least >>> the TextMessage body is as expected). >>> >>> More news tomorrow, but I wanted you to know this bit. >>> >>> Thanks again for your help thus far. >>> >>> Mark. >>> >>> >>> >>> -----Original Message----- From: Robbie Gemmell >>> Sent: Wednesday, February 19, 2014 5:09 PM >>> >>> To: users@qpid.apache.org >>> Subject: Re: New User JMS API Questions >>> >>> I forced the nightly release job to run a little early, you should now >>> find >>> binaries with the change included at: >>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid- >>> Java-Artefact-Release/lastSuccessfulBuild/artifact/ >>> trunk/qpid/java/amqp-1-0-client-jms/release/ >>> >>> Alternatively you can use the maven artefacts from the snapshots repo at: >>> https://repository.apache.org/content/repositories/snapshots/ >>> >>> <dependency> >>> <groupId>org.apache.qpid</groupId> >>> <artifactId>qpid-amqp-1-0-client-jms</artifactId> >>> <version>0.28-SNAPSHOT</version> >>> </dependency> >>> >>> Robbie >>> >>> On 19 February 2014 20:53, Rob Godfrey wrote: >>> >>> OK, I've checked in a change to the trunk codebase so that the Qpid >>>> DestinationImpl object no longer implements javax.jms.Queue and >>>> javax.jms.Topic interfaces... I think this should help ActiveMQ to cope >>>> with it... >>>> >>>> If you want to test this you'll need to check out the source code from >>>> here: >>>> >>>> http://svn.apache.org/repos/asf/qpid/trunk/qpid/ >>>> >>>> Go to the java subdirectory, and build using ant (e.g. "ant build"). The >>>> built libraries will then be in the build/lib subdirectory (you'll only >>>> want the amqp-1-0-*0.27.jar files). >>>> >>>> Let me know if you manage to get it working or encounter any more issues. >>>> >>>> >>>> Cheers, >>>> >>>> Rob >>>> >>>> >>>> and >>>> >>>> >>>>> On 19 February 2014 21:42, Rob Godfrey wrote: >>>>> >>>>> OK... looking up their code tree a bit I see why it gets confused by >>>> the >>>>> Qpid destination... because the Qpid AMQP 1.0 DestinationImpl >>>> implements >>>>> both Queue and Topic... I'm not sure why it does that (probably a >>>>> historical artefact). If I change that in Qpid, it might make ActiveMQ >>>>> happier... >>>>> >>>>> -- Rob >>>>> >>>>> >>>>>> On 19 February 2014 21:10, Rob Godfrey wrote: >>>>>> >>>>>> Ah interesting... it's ActiveMQ code that is throwing the exception... >>>> As >>>>>> per the JMS contract, the Qpid message producer is setting the >>>>>> JMSDestination on the message it is sending (in this case a foreign >>>>>> message, namely an ActiveMQ message). The ActiveMQ message class >>>> doesn't >>>>>> seem to like having a destination set on it which isn't one that it >>>> can >>>>>> resolve (even though it doesn't need to). The code in question >>>> appears >>>> to >>>>>> be here in the activeMQ codebase: >>>> http://grepcode.com/file/repo1.maven.org/maven2/org. >>>> apache.activemq/activemq-core/5.6.0/org/apache/activemq/command/ >>>> DefaultUnresolvedDestinationTransformer.java >>>>>> >>>>>> It looks like ActiveMQ is requiring Queue and Topic implementations to >>>>>> implement the methods isQueue() and/or isTopic()... but these are not >>>> part >>>>>> of the API defined for JMS Queues and topics AFAIK (see >>>>>> http://docs.oracle.com/javaee/6/api/javax/jms/Queue.html for >>>> example). >>>>>> So I think that ActiveMQ is in error / violation of the JMS spec here >>>>>> (though Robbie who has been reading the JMS spec carefully lately may >>>>>> be >>>>>> able to give better advice). If ActiveMQ is absolutely determined to >>>> turn >>>>>> the destination object into an ActiveMQ one, I'm not entirely sure why >>>> the >>>>>> ActiveMQ code doesn't fall back to an instanceof test to determine >>>> whether >>>>>> the the passed in Destination is a Queue (or if not a Topic)... >>>>>> >>>>>> -- Rob >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org