Hi Mark,
On 19 February 2014 05:23, Mark Barker <[email protected]> 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: [email protected]
> 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 "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: [email protected]
>> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
