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