You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@camel.apache.org by Mark Borner <ma...@zurich.com.au> on 2011/12/22 23:46:52 UTC

Camel JMS Request/Reply with Websphere

Hello:

I'm trying to use Camel (v 2.6.0) JMS Request/Reply with Websphere 7 using 
Websphere MQ.  I'm successfully able to put the request message onto the 
queue using the following URI:

jms:queue:inboundQueue?connectionFactory=#connectionFactory&taskExecutor=#taskExecutor&transactionManager=#transactionManager&cacheLevelName=CACHE_NONE&replyTo=outboundQueue&requestTimeout=120000

Note: I have to use cacheLevelName=CACHE_NONE in order for this to work on 
Websphere.

However, when Camel creates the PersistentQueueMessageListenerContainer to 
read the reply message, it is hard coding the cache level to CACHE_SESSION 
(see PersistentQueueReplyManager.java line 192).  What happens is that 
Camel is successfully able to read the reply off the queue, but then spits 
out the following error repeatedly:

23 Dec 2011 09:23:32,427|||WorkManager.DefaultWorkManager : 3||WARN 
|org.springframework.jms.listener.DefaultMessageListenerContainer|Setup of 
JMS message listener invoker failed for destination 'temporary' - trying 
to recover. Cause: Connection closed

I believe this is due to the PersistentQueueMessageListenerContainer using 
a cache level of CACHE_SESSION instead of CACHE_NONE.

Can you please confirm there is no way to set the cache level on the 
PersistentQueueMessageListenerContainer that Camel creates?

Can Camel be enhanced to either a) use the cache level from the request 
queue, or b) have the ability to set the cache level on the reply queue?

Thanks,
Mark

Mark Borner
Java Developer - ZStream Xpress






----
This email is intended for the named recipient only. It may contain 
information which is confidential, commercially sensitive, or 
copyright. If you are not the intended recipient you must not 
reproduce or distribute any part of the email, disclose its contents, 
or take any action in reliance. If you have received this email in 
error, please contact the sender and delete the message. It is your 
responsibility to scan this email and any attachments for viruses and 
other defects. To the extent permitted by law, Zurich and its 
associates will not be liable for any loss or damage arising in any 
way from this communication including any file attachments. We may 
monitor email you send to us, either as a reply to this email or any 
email you send to us, to confirm our systems are protected and for 
compliance with company policies. Although we take reasonable 
precautions to protect the confidentiality of our email systems, we 
do not warrant the confidentiality or security of email or 
attachments we receive.

Re: Camel JMS Request/Reply with Websphere

Posted by wing-tung Leung <wi...@gmail.com>.

On Thu, Dec 22, 2011 at 11:46 PM, Mark Borner <ma...@zurich.com.au>wrote:

>
> I'm trying to use Camel (v 2.6.0) JMS Request/Reply with Websphere 7 using
> Websphere MQ.  I'm successfully able to put the request message onto the
> queue using the following URI:
>
>
> jms:queue:inboundQueue?connectionFactory=#connectionFactory&taskExecutor=#taskExecutor&transactionManager=#transactionManager&cacheLevelName=CACHE_NONE&replyTo=outboundQueue&requestTimeout=120000
>
> Note: I have to use cacheLevelName=CACHE_NONE in order for this to work on
> Websphere.
>

We work on WebSphere AS 6.1 in combination with WebSphere MQ as well, and I
also had trouble with the cache settings. Lowering cache level to
CACHE_NONE, seemed to solved the issue at first sight, but this leads to
intermediate JMS session resets, and in our case, possible lost messages
because we did not use any durable subscriptions. A colleague of mine
warned me for some problems he had with durable subscriptions in WebSphere
MQ, so I did not even try that particular setup.

Bringing the cache level to CACHE_CONSUMER solves the problem with lost
messages, but this is not compatible with the default WAS work manager. The
latter uses some kind of asynchronous internal beans, which REQUIRE closing
JMS connections at the end of each call.

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fasyncbns%2Fconcepts%2Fcasb_asbover.html

The trick to solve this: don't use the WAS work manager, but use some
simple Spring thread pool based executor instead.

So, maybe you can give this a try for you as well ..

Tung