Sorry, the logged error message stating 'temporary' was from when I was testing a temporary reply queue. The error message is the same if I used a fixed reply queue name.
I have created Jira CAMEL-4839. Thanks, Mark Mark Borner Java Developer - ZStream Xpress From: Claus Ibsen <claus.ib...@gmail.com> To: users@camel.apache.org Date: 23/12/2011 06:40 PM Subject: Re: Camel JMS Request/Reply with Websphere Hi On Thu, Dec 22, 2011 at 11:46 PM, Mark Borner <mark.bor...@zurich.com.au>wrote: > > 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 > > If you use fixed reply to queue's then why do you use 'temporary' as queue name? > 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? > > This cannot be configured. Feel free to create a JIRA ticket to enhance this. > 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? > > It should be option b, so you can configure both of them individually. > 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. > > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/ ---- 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.
