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: [email protected]
>>> 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: [email protected]
For additional commands, e-mail: [email protected]
