I had problems as well using failover with maxRetryAttempts and PooledConnections. Might there be a call missing in FailoverTransport to the transportListener indicating a finally failed connection? Find attached a patch I applied successfully to AMQ-4.1.1. ( http://www.nabble.com/file/p14181174/FailoverTransport.java FailoverTransport.java )
Regards, Holger James.Strachan wrote: > > On 26/11/2007, Jason Rosenberg <[EMAIL PROTECTED]> wrote: >> >> I'm curious whether you've found a solution to this. I've seen also that >> if >> you use the maxReconnectAttempts, and it fails to reconnect, then the >> connection cannot be reliably recovered. > > If a connection fails to reconnect it must be discarded (along with > all of its associated resources). e.g. imagine a JDBC connection when > a database goes down - its of no real use any more > > >> I've tried it with the Jencks AMQPool for my connection pooling, as well >> as >> the standard ActiveMQ PooledConnections.... >> >> And if you don't use the maxReconnectAttempts flag, then it retries >> forever, >> and hangs the client. >> >> So, I'd be interested to know if there's a way to have it recover cleanly >> on >> failure, but always return quickly to the client if all failover choices >> have failed.... > > Does switching to Spring's MessageListenerContainer stuff instead of > the Jencks pool help? Basically the pool must ditch the connections, > sessions & consumers if the connection fails. > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > > -- View this message in context: http://www.nabble.com/Timeout-and-Failover-on-a-queue-tf4652630s2354.html#a14181174 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
