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 >> >
