qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Barker <mark.bar...@shaw.ca>
Subject Re: New User JMS API Questions
Date Wed, 19 Feb 2014 19:01:37 GMT
Hi Rob,
Here is the stack trace. The line (72) in Listener.java (app code) that is failing is just:
where messageProducer2 is a MessageProducer from the Qpid connection/session,
and msg is just a “Message” which was received from Q1 just prior, via the Openwire transport
(from its own connection/session).
javax.jms.JMSException: Unresolvable destination: org.apache.qpid.amqp_1_0.jms.impl.QueueImpl.isQueue():
                at org.apache.activemq.command.DefaultUnresolvedDestinationTransformer.transform(DefaultUnresolvedDestinationTransformer.java:48)
                at org.apache.activemq.command.ActiveMQDestination.transform(ActiveMQDestination.java:132)
                at org.apache.activemq.command.ActiveMQMessage.setJMSDestination(ActiveMQMessage.java:243)
                at org.apache.qpid.amqp_1_0.jms.impl.MessageProducerImpl.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.

Sent from my iPhone

> On Feb 19, 2014, at 1:51, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> Hi Mark,
>> On 19 February 2014 05:23, Mark Barker <mark.barker@shaw.ca> 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 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
>> 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.
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message