On 21 February 2014 01:15, Mark Barker <mark.bar...@shaw.ca> wrote: > 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. > > Hmmm - it was OK with 0.26 but not 0.27 (trunk)... I'll have to look into that then
> * 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. > > Would it be possible for you to attach the test programs you are running to a JIRA ( https://issues.apache.org/jira/browse/QPID<https://issues.apache.org/jira/browse/QPID-5455> ) and I'll try to replicate what you are seeing tomorrow (or to be accurate, later today - it being 1:35am here :-) ). Unfortunately the mailing list strips attachments sent in mails. Thanks, Rob > > 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 > >
