Hi,

I think you need to ask the configuration question on ActiveMQ mailing list. As camel-jms nothing about about the underlay MQ's protocol. it can't be configured from camel :(

Willem


Ming Fang wrote:
Does anyone know of a fix for this? This is a critical problem for us, and for many I would think since this is a very typical configuration.

On Nov 19, 2009, at 6:59 AM, Ming Fang wrote:

Yes changing idelTimeOut in org.apache.activemq.pool.ConnectionPool to a very 
large number would be a workaround.
However I don't see anyway of doing that in 
org.apache.activemq.camel.component.ActiveMQConfiguration.

But ultimately I think the way Camel uses JMS is just wrong;
The use of a Requestor to listen for out messages will always be a problem 
because it's not guarantee to be listening on the same broker as the publisher.
--ming

On Nov 19, 2009, at 4:42 AM, Willem Jiang wrote:

Hi,

How about change the idle time of switching the broker ?

If the idle time is larger than your application response time, you will not 
get this kind trouble anymore.

Willem

Ming Fang wrote:
Hi
We're using Camel 2.0 with Activemq 5.3.
Our app uses Camel jms remoting.
It's connecting to two discrete ActiveMQ brokers using the failover transport 
randomly. Everything works fine at first.
The problem happens when the app is idle for more than 30 seconds. After that 
any remote call will trigger Activemq client to reconnect and may end up 
connecting to another broker. But the problem is the Requestor does not 
reconnect and still connected to the original broker. The result is calls are 
sent to one broker but the Requestor is listening to a different broker for the 
response.
Is there a way to force the Requestor to use the same connection as the 
producers?
--Ming



Reply via email to