Re: New User JMS API Questions
The patch was indicated to have been tested against the ActiveMQ trunk / 5.10-SNAPSHOT, so something probably changed on the ActiveMQ side since 5.9.0 was released. Probably this: https://issues.apache.org/jira/browse/AMQ-4741 Robbie On 21 February 2014 00:49, Rob Godfrey wrote: > On 21 February 2014 01:38, Rob Godfrey wrote: > > > > > > > > > On 21 February 2014 01:15, Mark Barker 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 > > > > On a second look, it does appear that the synchronous publishing fix ( > https://issues.apache.org/jira/browse/QPID-5455) wasn't actually in > 0.26... > so my guess would be that ActiveMQ is not sending back the required > synchronous response - although they did say they had tested it... I'll > have a go at testing with ActiveMQ tmr to confirm. If all else fails I can > always add in an option to revert to the original (incorrect) behaviour of > publishing asynchronously > > -- Rob >
Re: New User JMS API Questions
Hi Rob, I've registered an account and opened JIRA QPID-5573 https://issues.apache.org/jira/browse/QPID-5573 I think you've already seen it. I've attached the files I have "developed" for this test scenario. Shouldn't be anything complicated. I'm not using an IDE or anything, so everything is just command-line driven. I'm not at work, so it was an effort to grab these files :) Anyway, no rush - I'm not back in-office until Monday anyway. Please let me know if there's more I can attach or provide, or if you need more information on the test environment/scenario. Thanks again, Mark. -Original Message- From: Rob Godfrey Sent: Thursday, February 20, 2014 5:49 PM To: users@qpid.apache.org Subject: Re: New User JMS API Questions On 21 February 2014 01:38, Rob Godfrey wrote: On 21 February 2014 01:15, Mark Barker 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 On a second look, it does appear that the synchronous publishing fix ( https://issues.apache.org/jira/browse/QPID-5455) wasn't actually in 0.26... so my guess would be that ActiveMQ is not sending back the required synchronous response - although they did say they had tested it... I'll have a go at testing with ActiveMQ tmr to confirm. If all else fails I can always add in an option to revert to the original (incorrect) behaviour of publishing asynchronously -- Rob - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: New User JMS API Questions
On 21 February 2014 01:38, Rob Godfrey wrote: > > > > On 21 February 2014 01:15, Mark Barker 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 > On a second look, it does appear that the synchronous publishing fix ( https://issues.apache.org/jira/browse/QPID-5455) wasn't actually in 0.26... so my guess would be that ActiveMQ is not sending back the required synchronous response - although they did say they had tested it... I'll have a go at testing with ActiveMQ tmr to confirm. If all else fails I can always add in an option to revert to the original (incorrect) behaviour of publishing asynchronously -- Rob
Re: New User JMS API Questions
On 21 February 2014 01:15, Mark Barker 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 place
Re: New User JMS API Questions
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.o
Re: New User JMS API Questions
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/ >> >> >> org.apache.qpid >> qpid-amqp-1-0-client-jms >> 0.28-SNAPSHOT >> >> >> 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 >>>
Re: New User JMS API Questions
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/ > > > org.apache.qpid > qpid-amqp-1-0-client-jms > 0.28-SNAPSHOT > > > 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 > >
Re: New User JMS API Questions
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/ org.apache.qpid qpid-amqp-1-0-client-jms 0.28-SNAPSHOT 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
Re: New User JMS API Questions
oducerImpl.send(MessageProducerImpl.java:309)
> >>> at
> >>>
> org.apache.qpid.amqp_1_0.jms.impl.MessageProducerImpl.send(MessageProducerImpl.java:215)
> >>> at Listener.main(Listener.java:72)
> >>>
> >>> Is this enough to tell you what's happening?
> >>>
> >>> If not, please let me know what else I can provide to understand this
> >>> issue!
> >>> I can include code. It's only for testing purposes anyway.
> >>>
> >>> Thanks,
> >>> Mark.
> >>>
> >>> Sent from my iPhone
> >>>
> >>> > On Feb 19, 2014, at 1:51, Rob Godfrey
> wrote:
> >>> >
> >>> > Hi Mark,
> >>> >
> >>> >> On 19 February 2014 05:23, Mark Barker wrote:
> >>> >>
> >>> >> Thanks again to Rob and Robbie for their answers thus far!
> >>> >>
> >>> >> So I managed to slap (i.e. Frankenstein) together two pieces of
> >>> >> example/client code in order to attempt to facilitate a bridge of
> >>> sorts
> >>> >> between two disparate queues.
> >>> >>
> >>> >> For this test, I'm using an ActiveMQ broker with two client
> >>> processes/JVMs
> >>> >> (client1 and client2).
> >>> >> The ActiveMQ broker is configured with 2 active protocols (transport
> >>> >> connectors) - Openwire (standard) on port 61616, and AMQP (1.0) on
> >>> port
> >>> >> 5673 (only because I was experimenting previously with the Qpid
> >>> broker on
> >>> >> the more conventional port 5672) on the same box.
> >>> >>
> >>> >> client1 is a process based purely on an ActiveMQ Java/JMS openwire
> >>> client
> >>> >> (Publisher.java) example and its only purpose is to publish a
> >>> TextMessage
> >>> >> into Q1 via the openwire (tcp://) connection URL.
> >>> >>
> >>> >> client2 contains client code (and is linked/run with .jar libraries)
> >>> for
> >>> >> both ActiveMQ AND Qpid JMS (AMQP 1.0). Its intent is to read
> messages
> >>> from
> >>> >> Q1 (via ActiveMQ) and re-deliver them into Q2 (via AMQP). This
> >>> situation is
> >>> >> a little contrived to start with, as eventually Q2 may well be on a
> >>> >> physically separate broker on a physically separate machine.
> >>> >>
> >>> >> So far, so good. I did some basic testing and proved my single
> client2
> >>> >> process can successfully (independently) interact with both queues
> >>> (via
> >>> >> both protocols).
> >>> >>
> >>> >> My issue is now this:
> >>> >> If I receive a "TextMessage" in client2 using "consumer2" (a
> >>> >> MessageConsumer for the ActiveMQ connection/session), this message
> >>> >> object/entity ("msg") is not just something I can use (unaltered) to
> >>> "send"
> >>> >> via client2's "producer2" (a MessageProducer for the AMQP
> >>> >> connection/session). Indeed, if I just try and
> "producer2.send(msg)",
> >>> I get
> >>> >> a Java exception at runtime. Something like:
> >>> >> "javax.jms.JMSException: Unresolvable destination:
> >>> >> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl.isQueue():
> >>> >> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl@e127d8ab" on the "send"
> >>> call.
> >>> >>
> >>> >> I can only assume that this is because TextMessage has 2 separate
> >>> >> implementations context-dependant on the protocol/client interface
> >>> with
> >>> >> which we are dealing.
> >>> >> Some digging (printing out the .getClass() results) shows that the
> msg
> >>> >> received is something like an
> >>> org.apache.activemq.command.ActiveMQTextMessage,
> >>> >> and the message needed to be sent is actually an
> >>> >> org.apache.qpid.amqp_1_0.jms.impl.TestMessageImpl.
> >>> >>
> >>> >> If this is the case, what is the best way to solve this problem.
> >>> >> If msg
Re: New User JMS API Questions
ether two pieces of
>>> >> example/client code in order to attempt to facilitate a bridge of
>>> sorts
>>> >> between two disparate queues.
>>> >>
>>> >> For this test, I'm using an ActiveMQ broker with two client
>>> processes/JVMs
>>> >> (client1 and client2).
>>> >> The ActiveMQ broker is configured with 2 active protocols (transport
>>> >> connectors) - Openwire (standard) on port 61616, and AMQP (1.0) on
>>> port
>>> >> 5673 (only because I was experimenting previously with the Qpid
>>> broker on
>>> >> the more conventional port 5672) on the same box.
>>> >>
>>> >> client1 is a process based purely on an ActiveMQ Java/JMS openwire
>>> client
>>> >> (Publisher.java) example and its only purpose is to publish a
>>> TextMessage
>>> >> into Q1 via the openwire (tcp://) connection URL.
>>> >>
>>> >> client2 contains client code (and is linked/run with .jar libraries)
>>> for
>>> >> both ActiveMQ AND Qpid JMS (AMQP 1.0). Its intent is to read messages
>>> from
>>> >> Q1 (via ActiveMQ) and re-deliver them into Q2 (via AMQP). This
>>> situation is
>>> >> a little contrived to start with, as eventually Q2 may well be on a
>>> >> physically separate broker on a physically separate machine.
>>> >>
>>> >> So far, so good. I did some basic testing and proved my single client2
>>> >> process can successfully (independently) interact with both queues
>>> (via
>>> >> both protocols).
>>> >>
>>> >> My issue is now this:
>>> >> If I receive a "TextMessage" in client2 using "consumer2" (a
>>> >> MessageConsumer for the ActiveMQ connection/session), this message
>>> >> object/entity ("msg") is not just something I can use (unaltered) to
>>> "send"
>>> >> via client2's "producer2" (a MessageProducer for the AMQP
>>> >> connection/session). Indeed, if I just try and "producer2.send(msg)",
>>> I get
>>> >> a Java exception at runtime. Something like:
>>> >> "javax.jms.JMSException: Unresolvable destination:
>>> >> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl.isQueue():
>>> >> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl@e127d8ab" on the "send"
>>> call.
>>> >>
>>> >> I can only assume that this is because TextMessage has 2 separate
>>> >> implementations context-dependant on the protocol/client interface
>>> with
>>> >> which we are dealing.
>>> >> Some digging (printing out the .getClass() results) shows that the msg
>>> >> received is something like an
>>> org.apache.activemq.command.ActiveMQTextMessage,
>>> >> and the message needed to be sent is actually an
>>> >> org.apache.qpid.amqp_1_0.jms.impl.TestMessageImpl.
>>> >>
>>> >> If this is the case, what is the best way to solve this problem.
>>> >> If msg has a number of header and application-defined property
>>> attributes
>>> >> (never minding the body), how exactly is client2 supposed to
>>> copy/preserve
>>> >> them all across into a TextMessage object implementation suitable for
>>> >> delivery to Q2. Will client2 need to know the exact structure of the
>>> >> messages in order to deconstruct and reconstruct to satisfy the
>>> protocol
>>> >> bridging??
>>> >
>>> > So, in general a JMS library should be able to send a valid JMS message
>>> > created or received from a different JMS provider... these are known as
>>> > "foreign" messages in JMS terms. The exception is that Destinations
>>> (such
>>> > as those found in the JMSReplyTo field) are provider specific.
>>> However if
>>> > you don't have a ReplyTo set in the incoming message then I don't
>>> believe
>>> > there should be any other issues as long as the messages are conformant
>>> > with the JMS specification (note that many providers may "extend" the
>>> JMS
>>> > specification to allow for non standard behaviours such as allowing map
>>> > messages to contain nested maps or lists... such messages cannot be
>>> > guaranteed to be
Re: New User JMS API Questions
h .jar libraries)
>> for
>> >> both ActiveMQ AND Qpid JMS (AMQP 1.0). Its intent is to read messages
>> from
>> >> Q1 (via ActiveMQ) and re-deliver them into Q2 (via AMQP). This
>> situation is
>> >> a little contrived to start with, as eventually Q2 may well be on a
>> >> physically separate broker on a physically separate machine.
>> >>
>> >> So far, so good. I did some basic testing and proved my single client2
>> >> process can successfully (independently) interact with both queues (via
>> >> both protocols).
>> >>
>> >> My issue is now this:
>> >> If I receive a "TextMessage" in client2 using "consumer2" (a
>> >> MessageConsumer for the ActiveMQ connection/session), this message
>> >> object/entity ("msg") is not just something I can use (unaltered) to
>> "send"
>> >> via client2's "producer2" (a MessageProducer for the AMQP
>> >> connection/session). Indeed, if I just try and "producer2.send(msg)",
>> I get
>> >> a Java exception at runtime. Something like:
>> >> "javax.jms.JMSException: Unresolvable destination:
>> >> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl.isQueue():
>> >> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl@e127d8ab" on the "send"
>> call.
>> >>
>> >> I can only assume that this is because TextMessage has 2 separate
>> >> implementations context-dependant on the protocol/client interface with
>> >> which we are dealing.
>> >> Some digging (printing out the .getClass() results) shows that the msg
>> >> received is something like an
>> org.apache.activemq.command.ActiveMQTextMessage,
>> >> and the message needed to be sent is actually an
>> >> org.apache.qpid.amqp_1_0.jms.impl.TestMessageImpl.
>> >>
>> >> If this is the case, what is the best way to solve this problem.
>> >> If msg has a number of header and application-defined property
>> attributes
>> >> (never minding the body), how exactly is client2 supposed to
>> copy/preserve
>> >> them all across into a TextMessage object implementation suitable for
>> >> delivery to Q2. Will client2 need to know the exact structure of the
>> >> messages in order to deconstruct and reconstruct to satisfy the
>> protocol
>> >> bridging??
>> >
>> > So, in general a JMS library should be able to send a valid JMS message
>> > created or received from a different JMS provider... these are known as
>> > "foreign" messages in JMS terms. The exception is that Destinations
>> (such
>> > as those found in the JMSReplyTo field) are provider specific. However
>> if
>> > you don't have a ReplyTo set in the incoming message then I don't
>> believe
>> > there should be any other issues as long as the messages are conformant
>> > with the JMS specification (note that many providers may "extend" the
>> JMS
>> > specification to allow for non standard behaviours such as allowing map
>> > messages to contain nested maps or lists... such messages cannot be
>> > guaranteed to be resent without issue).
>> >
>> > Having said all of the above, I'm not sure that this is actually your
>> > issue... the error you are seeing sounds more like it is to do with
>> trying
>> > to send to a queue which doesn't exist, however I can't find the error
>> text
>> > you pasted in the Qpid codebase anywhere... Would it be possible to
>> paste
>> > in the complete stack trace (or at least all the bits that are within
>> the
>> > qpid code if you want to remove any confidential parts from your own
>> > program)?
>> >
>> > Thanks,
>> > Rob
>> >
>> >
>> >> As ever, any help with this would be hugely appreciated...
>> >> Thanks in advance,
>> >> Mark.
>> >>
>> >>
>> >> -Original Message- From: Rob Godfrey
>> >> Sent: Monday, February 17, 2014 5:54 PM
>> >>
>> >> To: users@qpid.apache.org
>> >> Subject: Re: New User JMS API Questions
>> >>
>> >> On 18 February 2014 01:11, Mark Barker wrote:
>> >>
>> >> Robbie,
>> >>> thanks again for your answers.
>> >>>
>> >>> As for your first suggestion:
>> >>&
Re: New User JMS API Questions
onsumer for the ActiveMQ connection/session), this message
> >> object/entity ("msg") is not just something I can use (unaltered) to
> "send"
> >> via client2's "producer2" (a MessageProducer for the AMQP
> >> connection/session). Indeed, if I just try and "producer2.send(msg)", I
> get
> >> a Java exception at runtime. Something like:
> >> "javax.jms.JMSException: Unresolvable destination:
> >> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl.isQueue():
> >> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl@e127d8ab" on the "send"
> call.
> >>
> >> I can only assume that this is because TextMessage has 2 separate
> >> implementations context-dependant on the protocol/client interface with
> >> which we are dealing.
> >> Some digging (printing out the .getClass() results) shows that the msg
> >> received is something like an
> org.apache.activemq.command.ActiveMQTextMessage,
> >> and the message needed to be sent is actually an
> >> org.apache.qpid.amqp_1_0.jms.impl.TestMessageImpl.
> >>
> >> If this is the case, what is the best way to solve this problem.
> >> If msg has a number of header and application-defined property
> attributes
> >> (never minding the body), how exactly is client2 supposed to
> copy/preserve
> >> them all across into a TextMessage object implementation suitable for
> >> delivery to Q2. Will client2 need to know the exact structure of the
> >> messages in order to deconstruct and reconstruct to satisfy the protocol
> >> bridging??
> >
> > So, in general a JMS library should be able to send a valid JMS message
> > created or received from a different JMS provider... these are known as
> > "foreign" messages in JMS terms. The exception is that Destinations
> (such
> > as those found in the JMSReplyTo field) are provider specific. However
> if
> > you don't have a ReplyTo set in the incoming message then I don't believe
> > there should be any other issues as long as the messages are conformant
> > with the JMS specification (note that many providers may "extend" the JMS
> > specification to allow for non standard behaviours such as allowing map
> > messages to contain nested maps or lists... such messages cannot be
> > guaranteed to be resent without issue).
> >
> > Having said all of the above, I'm not sure that this is actually your
> > issue... the error you are seeing sounds more like it is to do with
> trying
> > to send to a queue which doesn't exist, however I can't find the error
> text
> > you pasted in the Qpid codebase anywhere... Would it be possible to
> paste
> > in the complete stack trace (or at least all the bits that are within the
> > qpid code if you want to remove any confidential parts from your own
> > program)?
> >
> > Thanks,
> > Rob
> >
> >
> >> As ever, any help with this would be hugely appreciated...
> >> Thanks in advance,
> >> Mark.
> >>
> >>
> >> -Original Message- From: Rob Godfrey
> >> Sent: Monday, February 17, 2014 5:54 PM
> >>
> >> To: users@qpid.apache.org
> >> Subject: Re: New User JMS API Questions
> >>
> >> On 18 February 2014 01:11, Mark Barker wrote:
> >>
> >> Robbie,
> >>> thanks again for your answers.
> >>>
> >>> As for your first suggestion:
> >>>
> >>> "connecting an ActiveMQ JMS client to the ActiveMQ
> >>> broker and a Qpid JMS client to the Qpid broker within the same JVM"
> >>>
> >>> Is this going to be possible in practice? I'm something of a novice at
> >>> Java too. Will there be some kind of conflict if trying to use both the
> >>> ActiveMQ JMS client and the Qpid JMS client APIs in the same process?
> How
> >>> would/could this be done (example build command)? Thus far I have been
> >>> building simple example code from the command line and referencing the
> >>> relevant .jar dependency in the classpath params for both javac (build)
> >>> and
> >>> java (runtime).
> >>>
> >>>
> >>> There shouldn't be an issue as long as there are no conflicts between
> the
> >> dependencies of the ActiveMQ client and the Qpid client. The Qpid
> clients
> >> aim to have as few dependencies as possible, so there really shouldn't
> be
> >> an issue.
> >>
Re: New User JMS API Questions
n" messages in JMS terms. The exception is that Destinations (such > as those found in the JMSReplyTo field) are provider specific. However if > you don't have a ReplyTo set in the incoming message then I don't believe > there should be any other issues as long as the messages are conformant > with the JMS specification (note that many providers may "extend" the JMS > specification to allow for non standard behaviours such as allowing map > messages to contain nested maps or lists... such messages cannot be > guaranteed to be resent without issue). > > Having said all of the above, I'm not sure that this is actually your > issue... the error you are seeing sounds more like it is to do with trying > to send to a queue which doesn't exist, however I can't find the error text > you pasted in the Qpid codebase anywhere... Would it be possible to paste > in the complete stack trace (or at least all the bits that are within the > qpid code if you want to remove any confidential parts from your own > program)? > > Thanks, > Rob > > >> As ever, any help with this would be hugely appreciated... >> Thanks in advance, >> Mark. >> >> >> -Original Message- From: Rob Godfrey >> Sent: Monday, February 17, 2014 5:54 PM >> >> To: users@qpid.apache.org >> Subject: Re: New User JMS API Questions >> >> On 18 February 2014 01:11, Mark Barker wrote: >> >> Robbie, >>> thanks again for your answers. >>> >>> As for your first suggestion: >>> >>> "connecting an ActiveMQ JMS client to the ActiveMQ >>> broker and a Qpid JMS client to the Qpid broker within the same JVM" >>> >>> Is this going to be possible in practice? I'm something of a novice at >>> Java too. Will there be some kind of conflict if trying to use both the >>> ActiveMQ JMS client and the Qpid JMS client APIs in the same process? How >>> would/could this be done (example build command)? Thus far I have been >>> building simple example code from the command line and referencing the >>> relevant .jar dependency in the classpath params for both javac (build) >>> and >>> java (runtime). >>> >>> >>> There shouldn't be an issue as long as there are no conflicts between the >> dependencies of the ActiveMQ client and the Qpid client. The Qpid clients >> aim to have as few dependencies as possible, so there really shouldn't be >> an issue. >> >> >> Finally, >>> today I've been looking at getting the simple Hello.java example running >>> on the ActiveMQ broker. >>> Obviously, this means I have to use a JMS AMQP 1.0 client, so I've been >>> using the Qpid JMS 1.0 client. >>> I've encountered some issues which seem to relate to the Connection URL >>> syntax from the JNDI (hello.properties) file. >>> >>> For instance, >>> in a previous Qpid client talking AMQP 0-10 with a Qpid broker, I used: >>> amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672' >>> however I've read and seen in practice that this won't work with the 1.0 >>> client. >>> Instead I have to use something like: >>> amqp://username:password@localhost:5672 >>> >>> Can somebody please point me to the relevant documentation that explains >>> this difference in syntax. For all my digging on the Qpid website, I can >>> only find examples of the first/former (0-10 style), with no disclaimers >>> or >>> caveats regarding the 1.0 client. >>> >>> >>> No - there isn't a lot (or indeed really any) documentation around the >> AMQP >> 1.0 client. As you've noted the syntax is a little different from the 0-10 >> style... but you've pretty much got all of the syntax already. >> >> There are currently a number of options (set in the normal URI way: >> amqp://username:password@host:port?option1=value1&option2=value2...) to >> fine tune some AMQP settings. If you are interested you can look in the >> code which parses them here: >> >> https://svn.apache.org/viewvc/qpid/trunk/qpid/java/amqp-1-0- >> client-jms/src/main/java/org/apache/qpid/amqp_1_0/jms/impl/ >> ConnectionFactoryImpl.java?revision=1557982&view=markup&pathrev=1568703 >> >> Between lines 295 and 381 you will see the available options defined along >> with a brief description of their purpose. >> >> >> In addition, I've found I can use &quo
Re: New User JMS API Questions
Hi Mark,
On 19 February 2014 05:23, Mark Barker wrote:
> Thanks again to Rob and Robbie for their answers thus far!
>
> So I managed to slap (i.e. Frankenstein) together two pieces of
> example/client code in order to attempt to facilitate a bridge of sorts
> between two disparate queues.
>
> For this test, I'm using an ActiveMQ broker with two client processes/JVMs
> (client1 and client2).
> The ActiveMQ broker is configured with 2 active protocols (transport
> connectors) - Openwire (standard) on port 61616, and AMQP (1.0) on port
> 5673 (only because I was experimenting previously with the Qpid broker on
> the more conventional port 5672) on the same box.
>
> client1 is a process based purely on an ActiveMQ Java/JMS openwire client
> (Publisher.java) example and its only purpose is to publish a TextMessage
> into Q1 via the openwire (tcp://) connection URL.
>
> client2 contains client code (and is linked/run with .jar libraries) for
> both ActiveMQ AND Qpid JMS (AMQP 1.0). Its intent is to read messages from
> Q1 (via ActiveMQ) and re-deliver them into Q2 (via AMQP). This situation is
> a little contrived to start with, as eventually Q2 may well be on a
> physically separate broker on a physically separate machine.
>
> So far, so good. I did some basic testing and proved my single client2
> process can successfully (independently) interact with both queues (via
> both protocols).
>
> My issue is now this:
> If I receive a "TextMessage" in client2 using "consumer2" (a
> MessageConsumer for the ActiveMQ connection/session), this message
> object/entity ("msg") is not just something I can use (unaltered) to "send"
> via client2's "producer2" (a MessageProducer for the AMQP
> connection/session). Indeed, if I just try and "producer2.send(msg)", I get
> a Java exception at runtime. Something like:
> "javax.jms.JMSException: Unresolvable destination:
> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl.isQueue():
> org.apache.qpid.amqp_1_0.jms.impl.QueueImpl@e127d8ab" on the "send" call.
>
> I can only assume that this is because TextMessage has 2 separate
> implementations context-dependant on the protocol/client interface with
> which we are dealing.
> Some digging (printing out the .getClass() results) shows that the msg
> received is something like an org.apache.activemq.command.ActiveMQTextMessage,
> and the message needed to be sent is actually an
> org.apache.qpid.amqp_1_0.jms.impl.TestMessageImpl.
>
> If this is the case, what is the best way to solve this problem.
> If msg has a number of header and application-defined property attributes
> (never minding the body), how exactly is client2 supposed to copy/preserve
> them all across into a TextMessage object implementation suitable for
> delivery to Q2. Will client2 need to know the exact structure of the
> messages in order to deconstruct and reconstruct to satisfy the protocol
> bridging??
>
So, in general a JMS library should be able to send a valid JMS message
created or received from a different JMS provider... these are known as
"foreign" messages in JMS terms. The exception is that Destinations (such
as those found in the JMSReplyTo field) are provider specific. However if
you don't have a ReplyTo set in the incoming message then I don't believe
there should be any other issues as long as the messages are conformant
with the JMS specification (note that many providers may "extend" the JMS
specification to allow for non standard behaviours such as allowing map
messages to contain nested maps or lists... such messages cannot be
guaranteed to be resent without issue).
Having said all of the above, I'm not sure that this is actually your
issue... the error you are seeing sounds more like it is to do with trying
to send to a queue which doesn't exist, however I can't find the error text
you pasted in the Qpid codebase anywhere... Would it be possible to paste
in the complete stack trace (or at least all the bits that are within the
qpid code if you want to remove any confidential parts from your own
program)?
Thanks,
Rob
> As ever, any help with this would be hugely appreciated...
> Thanks in advance,
> Mark.
>
>
> -Original Message- From: Rob Godfrey
> Sent: Monday, February 17, 2014 5:54 PM
>
> To: users@qpid.apache.org
> Subject: Re: New User JMS API Questions
>
> On 18 February 2014 01:11, Mark Barker wrote:
>
> Robbie,
>> thanks again for your answers.
>>
>> As for your first suggestion:
>>
>> "connecting an ActiveMQ JMS client to the ActiveMQ
>> broker and a Qpid JMS client to the Qpid broker within the same JVM"
>>
>> Is this going to b
Re: New User JMS API Questions
Thanks again to Rob and Robbie for their answers thus far!
So I managed to slap (i.e. Frankenstein) together two pieces of
example/client code in order to attempt to facilitate a bridge of sorts
between two disparate queues.
For this test, I'm using an ActiveMQ broker with two client processes/JVMs
(client1 and client2).
The ActiveMQ broker is configured with 2 active protocols (transport
connectors) - Openwire (standard) on port 61616, and AMQP (1.0) on port 5673
(only because I was experimenting previously with the Qpid broker on the
more conventional port 5672) on the same box.
client1 is a process based purely on an ActiveMQ Java/JMS openwire client
(Publisher.java) example and its only purpose is to publish a TextMessage
into Q1 via the openwire (tcp://) connection URL.
client2 contains client code (and is linked/run with .jar libraries) for
both ActiveMQ AND Qpid JMS (AMQP 1.0). Its intent is to read messages from
Q1 (via ActiveMQ) and re-deliver them into Q2 (via AMQP). This situation is
a little contrived to start with, as eventually Q2 may well be on a
physically separate broker on a physically separate machine.
So far, so good. I did some basic testing and proved my single client2
process can successfully (independently) interact with both queues (via both
protocols).
My issue is now this:
If I receive a "TextMessage" in client2 using "consumer2" (a MessageConsumer
for the ActiveMQ connection/session), this message object/entity ("msg") is
not just something I can use (unaltered) to "send" via client2's "producer2"
(a MessageProducer for the AMQP connection/session). Indeed, if I just try
and "producer2.send(msg)", I get a Java exception at runtime. Something
like:
"javax.jms.JMSException: Unresolvable destination:
org.apache.qpid.amqp_1_0.jms.impl.QueueImpl.isQueue():
org.apache.qpid.amqp_1_0.jms.impl.QueueImpl@e127d8ab" on the "send" call.
I can only assume that this is because TextMessage has 2 separate
implementations context-dependant on the protocol/client interface with
which we are dealing.
Some digging (printing out the .getClass() results) shows that the msg
received is something like an
org.apache.activemq.command.ActiveMQTextMessage, and the message needed to
be sent is actually an org.apache.qpid.amqp_1_0.jms.impl.TestMessageImpl.
If this is the case, what is the best way to solve this problem.
If msg has a number of header and application-defined property attributes
(never minding the body), how exactly is client2 supposed to copy/preserve
them all across into a TextMessage object implementation suitable for
delivery to Q2. Will client2 need to know the exact structure of the
messages in order to deconstruct and reconstruct to satisfy the protocol
bridging??
As ever, any help with this would be hugely appreciated...
Thanks in advance,
Mark.
-Original Message-
From: Rob Godfrey
Sent: Monday, February 17, 2014 5:54 PM
To: users@qpid.apache.org
Subject: Re: New User JMS API Questions
On 18 February 2014 01:11, Mark Barker wrote:
Robbie,
thanks again for your answers.
As for your first suggestion:
"connecting an ActiveMQ JMS client to the ActiveMQ
broker and a Qpid JMS client to the Qpid broker within the same JVM"
Is this going to be possible in practice? I'm something of a novice at
Java too. Will there be some kind of conflict if trying to use both the
ActiveMQ JMS client and the Qpid JMS client APIs in the same process? How
would/could this be done (example build command)? Thus far I have been
building simple example code from the command line and referencing the
relevant .jar dependency in the classpath params for both javac (build)
and
java (runtime).
There shouldn't be an issue as long as there are no conflicts between the
dependencies of the ActiveMQ client and the Qpid client. The Qpid clients
aim to have as few dependencies as possible, so there really shouldn't be
an issue.
Finally,
today I've been looking at getting the simple Hello.java example running
on the ActiveMQ broker.
Obviously, this means I have to use a JMS AMQP 1.0 client, so I've been
using the Qpid JMS 1.0 client.
I've encountered some issues which seem to relate to the Connection URL
syntax from the JNDI (hello.properties) file.
For instance,
in a previous Qpid client talking AMQP 0-10 with a Qpid broker, I used:
amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672'
however I've read and seen in practice that this won't work with the 1.0
client.
Instead I have to use something like:
amqp://username:password@localhost:5672
Can somebody please point me to the relevant documentation that explains
this difference in syntax. For all my digging on the Qpid website, I can
only find examples of the first/former (0-10 style), with no disclaimers
or
caveats regarding the 1.
Re: New User JMS API Questions
On 18 February 2014 01:11, Mark Barker wrote: > Robbie, > thanks again for your answers. > > As for your first suggestion: > > "connecting an ActiveMQ JMS client to the ActiveMQ > broker and a Qpid JMS client to the Qpid broker within the same JVM" > > Is this going to be possible in practice? I'm something of a novice at > Java too. Will there be some kind of conflict if trying to use both the > ActiveMQ JMS client and the Qpid JMS client APIs in the same process? How > would/could this be done (example build command)? Thus far I have been > building simple example code from the command line and referencing the > relevant .jar dependency in the classpath params for both javac (build) and > java (runtime). > > There shouldn't be an issue as long as there are no conflicts between the dependencies of the ActiveMQ client and the Qpid client. The Qpid clients aim to have as few dependencies as possible, so there really shouldn't be an issue. > Finally, > today I've been looking at getting the simple Hello.java example running > on the ActiveMQ broker. > Obviously, this means I have to use a JMS AMQP 1.0 client, so I've been > using the Qpid JMS 1.0 client. > I've encountered some issues which seem to relate to the Connection URL > syntax from the JNDI (hello.properties) file. > > For instance, > in a previous Qpid client talking AMQP 0-10 with a Qpid broker, I used: > amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672' > however I've read and seen in practice that this won't work with the 1.0 > client. > Instead I have to use something like: > amqp://username:password@localhost:5672 > > Can somebody please point me to the relevant documentation that explains > this difference in syntax. For all my digging on the Qpid website, I can > only find examples of the first/former (0-10 style), with no disclaimers or > caveats regarding the 1.0 client. > > No - there isn't a lot (or indeed really any) documentation around the AMQP 1.0 client. As you've noted the syntax is a little different from the 0-10 style... but you've pretty much got all of the syntax already. There are currently a number of options (set in the normal URI way: amqp://username:password@host:port?option1=value1&option2=value2...) to fine tune some AMQP settings. If you are interested you can look in the code which parses them here: https://svn.apache.org/viewvc/qpid/trunk/qpid/java/amqp-1-0-client-jms/src/main/java/org/apache/qpid/amqp_1_0/jms/impl/ConnectionFactoryImpl.java?revision=1557982&view=markup&pathrev=1568703 Between lines 295 and 381 you will see the available options defined along with a brief description of their purpose. > In addition, I've found I can use "queue://" or "topic://" prefixes in the > JNDI properties to specify the object type when using the generic interface > (i.e. general instead of p2p/pub-sub). Is that syntax a feature of the AMQP > protocol, or something specific to the Qpid client or ActiveMQ broker? I > can't find much mention of it anywhere. > > That's something specific to the ActiveMQ broker. > Thanks again for giving these questions your attention!! > > > -- Rob > > -Original Message- From: Robbie Gemmell > Sent: Saturday, February 15, 2014 2:57 PM > > To: users@qpid.apache.org > Subject: Re: New User JMS API Questions > > On 14 February 2014 04:55, Mark Barker wrote: > > If anyone has a tried this, or can confirm: >> will it be possible to have a JMS client using an ActiveMQ broker on one >> machine (or maybe a producer/consumer pair), ultimately sending a message >> which then routes to a Qpid broker and associated local JMS consumer on a >> second machine (preserving all standard and application-specific JMS >> message headers/properties). Has this been done and are there further >> tricks, considerations and caveats here? >> Maybe the ActiveMQ JMS consumer process on the first machine makes the >> routing decision and then places the message via a producer instance for >> the Qpid broker on the 2nd machine? >> > > It sounds like you are talking about bridging two brokers, which you > presumably do either by connecting an ActiveMQ JMS client to the ActiveMQ > broker and a Qpid JMS client to the Qpid broker within the same JVM, or by > using the Qpid AMQP 1.0 JMS client to connect to both brokers. > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: New User JMS API Questions
Robbie, thanks again for your answers. As for your first suggestion: "connecting an ActiveMQ JMS client to the ActiveMQ broker and a Qpid JMS client to the Qpid broker within the same JVM" Is this going to be possible in practice? I'm something of a novice at Java too. Will there be some kind of conflict if trying to use both the ActiveMQ JMS client and the Qpid JMS client APIs in the same process? How would/could this be done (example build command)? Thus far I have been building simple example code from the command line and referencing the relevant .jar dependency in the classpath params for both javac (build) and java (runtime). Finally, today I've been looking at getting the simple Hello.java example running on the ActiveMQ broker. Obviously, this means I have to use a JMS AMQP 1.0 client, so I've been using the Qpid JMS 1.0 client. I've encountered some issues which seem to relate to the Connection URL syntax from the JNDI (hello.properties) file. For instance, in a previous Qpid client talking AMQP 0-10 with a Qpid broker, I used: amqp://username:password@clientid/test?brokerlist='tcp://localhost:5672' however I've read and seen in practice that this won't work with the 1.0 client. Instead I have to use something like: amqp://username:password@localhost:5672 Can somebody please point me to the relevant documentation that explains this difference in syntax. For all my digging on the Qpid website, I can only find examples of the first/former (0-10 style), with no disclaimers or caveats regarding the 1.0 client. In addition, I've found I can use "queue://" or "topic://" prefixes in the JNDI properties to specify the object type when using the generic interface (i.e. general instead of p2p/pub-sub). Is that syntax a feature of the AMQP protocol, or something specific to the Qpid client or ActiveMQ broker? I can't find much mention of it anywhere. Thanks again for giving these questions your attention!! -Original Message- From: Robbie Gemmell Sent: Saturday, February 15, 2014 2:57 PM To: users@qpid.apache.org Subject: Re: New User JMS API Questions On 14 February 2014 04:55, Mark Barker wrote: If anyone has a tried this, or can confirm: will it be possible to have a JMS client using an ActiveMQ broker on one machine (or maybe a producer/consumer pair), ultimately sending a message which then routes to a Qpid broker and associated local JMS consumer on a second machine (preserving all standard and application-specific JMS message headers/properties). Has this been done and are there further tricks, considerations and caveats here? Maybe the ActiveMQ JMS consumer process on the first machine makes the routing decision and then places the message via a producer instance for the Qpid broker on the 2nd machine? It sounds like you are talking about bridging two brokers, which you presumably do either by connecting an ActiveMQ JMS client to the ActiveMQ broker and a Qpid JMS client to the Qpid broker within the same JVM, or by using the Qpid AMQP 1.0 JMS client to connect to both brokers. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: New User JMS API Questions
On 16 February 2014 09:53, Fraser Adams wrote: > On 15/02/14 21:55, Robbie Gemmell wrote: > >> [snip] >> >> >> In terms of a 'topic', this needs to be something that supports the >> semantics of the pub-sub model, but there are a number of ways to achieve >> that. We currently have brokers that have models containing 'exchanges' >> that have been used for that historically (in confunction with queues) and >> so that is still the case, but utilising that model for 1.0 can require >> some unecessary hoop jumping (e.g exchanges are made to route messages to >> queues for consumers to receive, meanting that 'receiving from an >> exchange' >> can necessitate creation of temporary subscription queues to give the >> requested semantics) so going forward there is scope for alternative >> behaviours allowed by the 1.0 model. E.g one could represent a topic as a >> 'special' queue which only drops messages once all the consumers have >> passed it. >> >> Robbie >> [snip] >> >> I'd agree with your comment that in 1.0 there are multiple ways to skin > the "topic" cat - indeed as illustrated by the use of Message Selectors to > address Clive's earlier use case, which is somewhat analogous to what you > describe above. However I'd hope that going forward any "alternative > behaviours" would be in addition to the current ones. > > I can see the appeal of a "'special' queue which only drops messages once > all the consumers have passed it. " but from my parochial perspective my > most common use cases involve shared subscription queues that do *not* > autodelete. Don't read into the above as being a fully formed example of something I'm proposing we will implement, it was just a very quick and simplistic example of there being multiple ways to achieve certain things and that some of the existing behaviour doesn't necessarily make sense for 1.0. The particular issue is obviously a lot more complicated when considering things fully, taking into view things like [shared] durable subscriptions, [shared] non-durable subscriptions, selectors, no-local, compatibility, etc etc, but that wasnt really the point of the mail. (not that it really matters, but to make it clearer...the simple example was really talking to the basic non-shared non-durable topic subscription case, with the idea being there wouldnt be any subscription queues at all and instead just the 'topic' and its subscriptions..tagging durable and shared subscriptions on top would obviously need specific handling to achieve the durable and shared aspects) > In other words when a consumer (a logical consumer scaled across multiple > hosts hence the shared queue) has subscribed it continues to be interested > in messages even if it happens to go away for a while and in the current > implementation messages build up on the subscription queue which can be > retrieved when the consumer comes back online. > So in topic terms that would be a shared durable subscription (or if you only had one of those 'logical consumers' its basically just a queue that got messages put on it through some means). > In your example above you could achieve a similar thing with say a large > circular queue, but with every message delivered onto said queue if you get > a mixture of fast and slow producers it's quite possible that the messages > from the slow producer take a disproportionate hit. > > The plus side of your approach is that absolute message order of the > producers gets preserved, which is potentially useful. > > So I think that there are advantages to both but definitely wouldn't want > to lose the existing semantics. > > Cheers, > Frase > > > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: New User JMS API Questions
On 15/02/14 21:55, Robbie Gemmell wrote: [snip] In terms of a 'topic', this needs to be something that supports the semantics of the pub-sub model, but there are a number of ways to achieve that. We currently have brokers that have models containing 'exchanges' that have been used for that historically (in confunction with queues) and so that is still the case, but utilising that model for 1.0 can require some unecessary hoop jumping (e.g exchanges are made to route messages to queues for consumers to receive, meanting that 'receiving from an exchange' can necessitate creation of temporary subscription queues to give the requested semantics) so going forward there is scope for alternative behaviours allowed by the 1.0 model. E.g one could represent a topic as a 'special' queue which only drops messages once all the consumers have passed it. Robbie [snip] I'd agree with your comment that in 1.0 there are multiple ways to skin the "topic" cat - indeed as illustrated by the use of Message Selectors to address Clive's earlier use case, which is somewhat analogous to what you describe above. However I'd hope that going forward any "alternative behaviours" would be in addition to the current ones. I can see the appeal of a "'special' queue which only drops messages once all the consumers have passed it. " but from my parochial perspective my most common use cases involve shared subscription queues that do *not* autodelete. In other words when a consumer (a logical consumer scaled across multiple hosts hence the shared queue) has subscribed it continues to be interested in messages even if it happens to go away for a while and in the current implementation messages build up on the subscription queue which can be retrieved when the consumer comes back online. In your example above you could achieve a similar thing with say a large circular queue, but with every message delivered onto said queue if you get a mixture of fast and slow producers it's quite possible that the messages from the slow producer take a disproportionate hit. The plus side of your approach is that absolute message order of the producers gets preserved, which is potentially useful. So I think that there are advantages to both but definitely wouldn't want to lose the existing semantics. Cheers, Frase - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: New User JMS API Questions
On 14 February 2014 04:55, Mark Barker wrote: > Thanks Robbie, that was a very helpful collection of useful insights - I > don't think I would have found or understood these points just by reading > around the web and docs!! > > FYI, my initial attempt at contributing to this list from my work email > account was doomed to failure as our work filters are blocking the list > subscription responses to which we need to reply in order to join in the > first place - hence my using my home account as the fallback. > > There are definitely some gems in those answers that help me better > understand what's going on under the covers in the Qpid JMS implementation > so thank you very much for taking the time to answer those points. By the > way, your point in your answers about moving the getTopicName() call > somewhat worked. When I moved it down a couple of lines as you suggested > for the first test specifying destination.topicExchange, the call no longer > returned 'null', but instead returned what seemed to be the binding key for > that scenario - i.e. '#'. In that way, it matches the topic.topicExchange > test, in which the same call returned "news-service2" which in that case > was the binding key there also. > > So it looks like the next tranche of effort will involve looking at the > possibilities of using JMS/Qpid clients/brokers in combination with > ActiveMQ clients/brokers. > I guess my main worry/concern before starting this exercise is just how > feasible this endeavour will be. > From what I understand, ActiveMQ is currently only compatibile with AMQP > 1.0, correct? > Correct, it implements its AMQP 1.0 support using the Qpid Proton AMQP 1.0 library. > > If anyone has a tried this, or can confirm: > will it be possible to have a JMS client using an ActiveMQ broker on one > machine (or maybe a producer/consumer pair), ultimately sending a message > which then routes to a Qpid broker and associated local JMS consumer on a > second machine (preserving all standard and application-specific JMS > message headers/properties). Has this been done and are there further > tricks, considerations and caveats here? > Maybe the ActiveMQ JMS consumer process on the first machine makes the > routing decision and then places the message via a producer instance for > the Qpid broker on the 2nd machine? It sounds like you are talking about bridging two brokers, which you presumably do either by connecting an ActiveMQ JMS client to the ActiveMQ broker and a Qpid JMS client to the Qpid broker within the same JVM, or by using the Qpid AMQP 1.0 JMS client to connect to both brokers. > Or maybe it would be possible to administratively configure the 2 brokers > to be linked in a manner similar to what I've been reading about > Federations of brokers?? > > Finally, does anyone know if it is possible to integrate a Qpid broker > into an ActiveMQ 'cluster' configuration?? From the very brief reading I've > done, it appears the Qpid cluster implementation may be somewhat different > in its concept... > I would be rather surprised if this were possible currently as what you are talking about is generally fairly provider-specific and is a level of integration beyond just being able to speak the same protocol, but I don't really have the necessary knowledge of ActiveMQ's clustering functionality to be able to answer if I'm honest. > Thanks once again for all the help as I get to grips with this new subject > matter. > > Mark > > > > -Original Message- From: Robbie Gemmell > Sent: Wednesday, February 12, 2014 11:09 AM > > To: users@qpid.apache.org > Subject: Re: New User JMS API Questions > > Hi Mark, > > Is your work email address registered on the list? if not the message may > be awaiting moderation. > > Part of the issue is that you are definitely tripping up on a mixture of > JNDI configuration, some of which is of the newer 'Address' syntax variety > and some which is of the older 'Binding URL' format supported by the JMS > client. > On top of that, you may be getting confused by the use of 'topic' as the > type of an AMQP 0-x exchange, and the name of a node type in the 'Address' > syntax supported by the various Qpid clients, and finally its use in JMS > and differing behaviour of the client depending on the syntax in use. > > On the terminology side: > > The 'topic' type of exchanges in AMQP 0-X support pattern matching for > routing, whereas the other exchange types don't. The 'Address' syntax uses > the 'topic' to describe a node that can provide pub-sub semantics, and in > the case of AMQP 0-10 that is take
Re: New User JMS API Questions
The core AMQP 1.0 spec doesn't define a broker model in the way that previous versions did, it instead deals with the semantics of transfering messages over 'links' between 'nodes' that have an 'address' (can you see some of the inspiration for naming some of the previously discussed things?). A node could be thought of a producer/consumer in a client, or a queue/topic in a broker...or anything really, it is essentially just a named entity. In terms of a 'topic', this needs to be something that supports the semantics of the pub-sub model, but there are a number of ways to achieve that. We currently have brokers that have models containing 'exchanges' that have been used for that historically (in confunction with queues) and so that is still the case, but utilising that model for 1.0 can require some unecessary hoop jumping (e.g exchanges are made to route messages to queues for consumers to receive, meanting that 'receiving from an exchange' can necessitate creation of temporary subscription queues to give the requested semantics) so going forward there is scope for alternative behaviours allowed by the 1.0 model. E.g one could represent a topic as a 'special' queue which only drops messages once all the consumers have passed it. Robbie On 13 February 2014 13:02, Jan Bares wrote: > Thanks Robbie, > > this is quite interesting stuff for QPID/AMQP newbies. How does this stuff > changes with AMQP 1.0? > > Thanks, Jan > > > -Original Message- > > From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] > > Sent: Wednesday, February 12, 2014 7:09 PM > > To: users@qpid.apache.org > > Subject: Re: New User JMS API Questions > > > > Hi Mark, > > > > Is your work email address registered on the list? if not the message may > > be awaiting moderation. > > > > Part of the issue is that you are definitely tripping up on a mixture of > > JNDI configuration, some of which is of the newer 'Address' syntax > variety > > and some which is of the older 'Binding URL' format supported by the JMS > > client. > > On top of that, you may be getting confused by the use of 'topic' as the > > type of an AMQP 0-x exchange, and the name of a node type in the > 'Address' > > syntax supported by the various Qpid clients, and finally its use in JMS > > and differing behaviour of the client depending on the syntax in use. > > > > On the terminology side: > > > > The 'topic' type of exchanges in AMQP 0-X support pattern matching for > > routing, whereas the other exchange types don't. The 'Address' syntax > uses > > the 'topic' to describe a node that can provide pub-sub semantics, and in > > the case of AMQP 0-10 that is taken to mean an exchange ~(of any type) > > with > > the name of the topic. The JMS client uses 'topic' in essentially the > same > > way when using the 'Address' syntax, but with the 'Binding URL' syntax > the > > topic name is used as the routing key when publishing the message to a > > particular exchange (whose name may be unrelated to the topic name, and > > usually is) or binding queues to the exchange to recieve messages. > > > > On the JMS client behaviour side: > > > > JNDI properties of the form "destination. = " are > > treated as 'Address' strings by default, but may be treated as > BindingURLs > > if desired (see at the bottom). "queue. = " and > > "topic. = " values in the JNDI file are treated as a > > shorthand form of BindingURL that results in Queue usage with bindings > and > > publications to the amq.direct exchange using the queue name as the key, > > and Topic usage with bindings and publications to the amq.topic exchange > > using the topic name as the key. > > > > In your first test, by specifying "destination.topicExchange = > > news-service2" you thus got an 'Address' based Destination. The client > > 'resolves' the Address string against the broker when you create your > > producer/consumer to determine if the address is actually for a queue or > a > > topic (i.e an exchange) node. Prior to that it is returning null from the > > 'getTopicName' method, whereas looking at the code I expect it would > > return > > you the exchange name if you move that line down bit. > > > > On your second test, by using "topic.topicExchange = news-service2" you > > ended up with a BindingURL based Destination, which in this case told the > > client to use t
Re: New User JMS API Questions
Thanks Robbie, that was a very helpful collection of useful insights - I don't think I would have found or understood these points just by reading around the web and docs!! FYI, my initial attempt at contributing to this list from my work email account was doomed to failure as our work filters are blocking the list subscription responses to which we need to reply in order to join in the first place - hence my using my home account as the fallback. There are definitely some gems in those answers that help me better understand what's going on under the covers in the Qpid JMS implementation so thank you very much for taking the time to answer those points. By the way, your point in your answers about moving the getTopicName() call somewhat worked. When I moved it down a couple of lines as you suggested for the first test specifying destination.topicExchange, the call no longer returned 'null', but instead returned what seemed to be the binding key for that scenario - i.e. '#'. In that way, it matches the topic.topicExchange test, in which the same call returned "news-service2" which in that case was the binding key there also. So it looks like the next tranche of effort will involve looking at the possibilities of using JMS/Qpid clients/brokers in combination with ActiveMQ clients/brokers. I guess my main worry/concern before starting this exercise is just how feasible this endeavour will be. From what I understand, ActiveMQ is currently only compatibile with AMQP 1.0, correct? If anyone has a tried this, or can confirm: will it be possible to have a JMS client using an ActiveMQ broker on one machine (or maybe a producer/consumer pair), ultimately sending a message which then routes to a Qpid broker and associated local JMS consumer on a second machine (preserving all standard and application-specific JMS message headers/properties). Has this been done and are there further tricks, considerations and caveats here? Maybe the ActiveMQ JMS consumer process on the first machine makes the routing decision and then places the message via a producer instance for the Qpid broker on the 2nd machine? Or maybe it would be possible to administratively configure the 2 brokers to be linked in a manner similar to what I've been reading about Federations of brokers?? Finally, does anyone know if it is possible to integrate a Qpid broker into an ActiveMQ 'cluster' configuration?? From the very brief reading I've done, it appears the Qpid cluster implementation may be somewhat different in its concept... Thanks once again for all the help as I get to grips with this new subject matter. Mark -Original Message- From: Robbie Gemmell Sent: Wednesday, February 12, 2014 11:09 AM To: users@qpid.apache.org Subject: Re: New User JMS API Questions Hi Mark, Is your work email address registered on the list? if not the message may be awaiting moderation. Part of the issue is that you are definitely tripping up on a mixture of JNDI configuration, some of which is of the newer 'Address' syntax variety and some which is of the older 'Binding URL' format supported by the JMS client. On top of that, you may be getting confused by the use of 'topic' as the type of an AMQP 0-x exchange, and the name of a node type in the 'Address' syntax supported by the various Qpid clients, and finally its use in JMS and differing behaviour of the client depending on the syntax in use. On the terminology side: The 'topic' type of exchanges in AMQP 0-X support pattern matching for routing, whereas the other exchange types don't. The 'Address' syntax uses the 'topic' to describe a node that can provide pub-sub semantics, and in the case of AMQP 0-10 that is taken to mean an exchange ~(of any type) with the name of the topic. The JMS client uses 'topic' in essentially the same way when using the 'Address' syntax, but with the 'Binding URL' syntax the topic name is used as the routing key when publishing the message to a particular exchange (whose name may be unrelated to the topic name, and usually is) or binding queues to the exchange to recieve messages. On the JMS client behaviour side: JNDI properties of the form "destination. = " are treated as 'Address' strings by default, but may be treated as BindingURLs if desired (see at the bottom). "queue. = " and "topic. = " values in the JNDI file are treated as a shorthand form of BindingURL that results in Queue usage with bindings and publications to the amq.direct exchange using the queue name as the key, and Topic usage with bindings and publications to the amq.topic exchange using the topic name as the key. In your first test, by specifying "destination.topicExchange = news-service2" you thus got an 'Address' based Destinat
RE: New User JMS API Questions
Thanks Robbie, this is quite interesting stuff for QPID/AMQP newbies. How does this stuff changes with AMQP 1.0? Thanks, Jan > -Original Message- > From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] > Sent: Wednesday, February 12, 2014 7:09 PM > To: users@qpid.apache.org > Subject: Re: New User JMS API Questions > > Hi Mark, > > Is your work email address registered on the list? if not the message may > be awaiting moderation. > > Part of the issue is that you are definitely tripping up on a mixture of > JNDI configuration, some of which is of the newer 'Address' syntax variety > and some which is of the older 'Binding URL' format supported by the JMS > client. > On top of that, you may be getting confused by the use of 'topic' as the > type of an AMQP 0-x exchange, and the name of a node type in the 'Address' > syntax supported by the various Qpid clients, and finally its use in JMS > and differing behaviour of the client depending on the syntax in use. > > On the terminology side: > > The 'topic' type of exchanges in AMQP 0-X support pattern matching for > routing, whereas the other exchange types don't. The 'Address' syntax uses > the 'topic' to describe a node that can provide pub-sub semantics, and in > the case of AMQP 0-10 that is taken to mean an exchange ~(of any type) > with > the name of the topic. The JMS client uses 'topic' in essentially the same > way when using the 'Address' syntax, but with the 'Binding URL' syntax the > topic name is used as the routing key when publishing the message to a > particular exchange (whose name may be unrelated to the topic name, and > usually is) or binding queues to the exchange to recieve messages. > > On the JMS client behaviour side: > > JNDI properties of the form "destination. = " are > treated as 'Address' strings by default, but may be treated as BindingURLs > if desired (see at the bottom). "queue. = " and > "topic. = " values in the JNDI file are treated as a > shorthand form of BindingURL that results in Queue usage with bindings and > publications to the amq.direct exchange using the queue name as the key, > and Topic usage with bindings and publications to the amq.topic exchange > using the topic name as the key. > > In your first test, by specifying "destination.topicExchange = > news-service2" you thus got an 'Address' based Destination. The client > 'resolves' the Address string against the broker when you create your > producer/consumer to determine if the address is actually for a queue or a > topic (i.e an exchange) node. Prior to that it is returning null from the > 'getTopicName' method, whereas looking at the code I expect it would > return > you the exchange name if you move that line down bit. > > On your second test, by using "topic.topicExchange = news-service2" you > ended up with a BindingURL based Destination, which in this case told the > client to use the "amq.topic" exchange and send the messages with a routing > key of "news-service2", and to bind a temporary queue to amq.topic with > the > binding key "new-service2". > > For your third test, using "queue.topicExchange = some_queue_name" got > you > a BindingURL based Destination, which told the client to use the > "amq.direct" exchange and send the messages with a routing key of > "some_queue_name". The consumer creation had the side effect of creating > the queue and binding it ot the amq.direct exchange, because you were > using > a BindingURL based destination an this is the historic consumer behaviour > the client had with that syntax. For the Address syntax, it doesnt do that > by default but you can make it do something similar using the options of > the Address string. > > Some other info: > > You can see more details of the Address syntax at the following location, > though it is more tailored to the C++ etc APIs and the JMS client doesn't > necessarily support all of the options in the same way: > http://qpid.apache.org/releases/qpid-0.24/programming/book/section- > addresses.html > > Some details of the expanded BindingURL format usable in the "destination." > JNDI entries is at: > https://cwiki.apache.org/confluence/display/qpid/BindingURLFormat > > You can change the clients default syntax at a client level by setting the > system property qpid.dest_syntax to the value BURL (or ADDR), or you can > prefix the part of the JNDI property to override the default, using > BURL: to indicate a BindingURL, or ADDR: to indicate an
Re: New User JMS API Questions
Hi Mark, Is your work email address registered on the list? if not the message may be awaiting moderation. Part of the issue is that you are definitely tripping up on a mixture of JNDI configuration, some of which is of the newer 'Address' syntax variety and some which is of the older 'Binding URL' format supported by the JMS client. On top of that, you may be getting confused by the use of 'topic' as the type of an AMQP 0-x exchange, and the name of a node type in the 'Address' syntax supported by the various Qpid clients, and finally its use in JMS and differing behaviour of the client depending on the syntax in use. On the terminology side: The 'topic' type of exchanges in AMQP 0-X support pattern matching for routing, whereas the other exchange types don't. The 'Address' syntax uses the 'topic' to describe a node that can provide pub-sub semantics, and in the case of AMQP 0-10 that is taken to mean an exchange ~(of any type) with the name of the topic. The JMS client uses 'topic' in essentially the same way when using the 'Address' syntax, but with the 'Binding URL' syntax the topic name is used as the routing key when publishing the message to a particular exchange (whose name may be unrelated to the topic name, and usually is) or binding queues to the exchange to recieve messages. On the JMS client behaviour side: JNDI properties of the form "destination. = " are treated as 'Address' strings by default, but may be treated as BindingURLs if desired (see at the bottom). "queue. = " and "topic. = " values in the JNDI file are treated as a shorthand form of BindingURL that results in Queue usage with bindings and publications to the amq.direct exchange using the queue name as the key, and Topic usage with bindings and publications to the amq.topic exchange using the topic name as the key. In your first test, by specifying "destination.topicExchange = news-service2" you thus got an 'Address' based Destination. The client 'resolves' the Address string against the broker when you create your producer/consumer to determine if the address is actually for a queue or a topic (i.e an exchange) node. Prior to that it is returning null from the 'getTopicName' method, whereas looking at the code I expect it would return you the exchange name if you move that line down bit. On your second test, by using "topic.topicExchange = news-service2" you ended up with a BindingURL based Destination, which in this case told the client to use the "amq.topic" exchange and send the messages with a routing key of "news-service2", and to bind a temporary queue to amq.topic with the binding key "new-service2". For your third test, using "queue.topicExchange = some_queue_name" got you a BindingURL based Destination, which told the client to use the "amq.direct" exchange and send the messages with a routing key of "some_queue_name". The consumer creation had the side effect of creating the queue and binding it ot the amq.direct exchange, because you were using a BindingURL based destination an this is the historic consumer behaviour the client had with that syntax. For the Address syntax, it doesnt do that by default but you can make it do something similar using the options of the Address string. Some other info: You can see more details of the Address syntax at the following location, though it is more tailored to the C++ etc APIs and the JMS client doesn't necessarily support all of the options in the same way: http://qpid.apache.org/releases/qpid-0.24/programming/book/section-addresses.html Some details of the expanded BindingURL format usable in the "destination." JNDI entries is at: https://cwiki.apache.org/confluence/display/qpid/BindingURLFormat You can change the clients default syntax at a client level by setting the system property qpid.dest_syntax to the value BURL (or ADDR), or you can prefix the part of the JNDI property to override the default, using BURL: to indicate a BindingURL, or ADDR: to indicate an Address. Robbie On 12 February 2014 03:14, Mark Barker wrote: > Apologies in advance if this shows up twice, but I seem to have had > problems sending from my work account... > > --- > > Hello. > > I have been playing around with the Hello.java example that came with > qpid-java-client-0.24.tar.gz. > I have installed the qpidd package (the broker) on a Ubuntu 12.04 LTS > platform along with the qpid-tools package > (from the Ubuntu Software Centre). > > I am looking to try and integrate the Qpid broker with JMS-based clients. > I am brand new to all of the concepts and my > understanding is possibly being confused by the differences in terminology > between JMS and Qpid elements. > I would greatly appreciate if you can indulge a few questions arising from > my initial foray... > > By modifying the code to use the pub/sub API, I have arrived at this > source (Hello2.java): > > > package org.apache.qpid.example; > import javax.jms.*; > import javax.naming.Context; > import javax.naming.InitialC
