camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Borner <mark.bor...@zurich.com.au>
Subject Re: Camel JMS Request/Reply with Websphere
Date Thu, 29 Dec 2011 00:26:28 GMT
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.ibsen@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.borner@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: cibsen@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.
Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message