I've created an issue to track this: AMQ-1575 I've posted a patch there, created originally by 'hbruch'....
Jason Jason Rosenberg wrote: > > Rob, > > The attempt to get a connection over the failover transport hangs (it goes > into it's reconnect sequence indefinitely).... > > What I'd like is for it to fail back to the caller (as if I had set a > maxReconnectAttempts param), but then it should be able to recover the if > the broker becomes available later, and I try again to get a connection. > > Basically, if I just use the tcpTransport, with no failover, the > connection fails immediately if no broker is available, but then if a > broker becomes available subsequently, connections work fine. > > I've been using the AMQPool (from Jencks), but the same thing happens for > the regular ActiveMQConnectionFactory.... > > Jason > > > > > rajdavies wrote: >> >> Hi Jason, >> >> on initialization of the transport with no brokers - you say it >> hangs ? - is that at the transport (tcp) level ? >> >> >> cheers, >> >> Rob >> >> http://open.iona.com/ -Enterprise Open Integration >> http://rajdavies.blogspot.com/ >> >> >> >> On Nov 16, 2007, at 11:12 PM, Jason Rosenberg wrote: >> >>> >>> Hello, >>> >>> I am trying to implement a solution based on the TransportListener, >>> in order >>> to use the FailoverTransport. >>> >>> Basically, I don't want to use the maxReconnectAttempts param for >>> FailoverTransport, because I want it to be self-recovering, and to >>> continue >>> retrying, etc. >>> >>> But, I do need it to respond quickly to the caller when no brokers are >>> available. >>> >>> So, I'm wondering what the recommended approach might be for >>> utilizing the >>> TransportListener. I have version up and running, which seems to >>> work ok, >>> in that I can set a listener on my connections and set an >>> 'availabilityStatus', etc....So, I don't attempt to make a >>> connection or >>> send a message, if the availabilityStatus is false, etc. >>> >>> However, I haven't figured out how to make it work if the app >>> initially >>> comes up the first time with no brokers available. In this case, the >>> initial connection attempt hangs, and so I never even get to the >>> point of >>> being able to add a transportListener, in the first place. >>> >>> I've tried doing things under the hood, like explicitly start an >>> 'initializingFailoverTransport' object, and set the listener to >>> that, prior >>> to the application being initialized. This seems to work ok, but >>> it seems >>> to cause the application to hang on shut-down, I haven't seemed to >>> figure >>> out how to make this 'initializingFailoverTransport' shut itself down >>> cleanly when everything shuts down.... >>> >>> I'm using Spring, so I use the InitializingBean and DisposableBean >>> interfaces to manage creation and closing of the >>> 'initializingFailoverTransport'.....(but this >>> initializingFailoverTransport >>> approach seems like a hack to me anyway, I'm not really happy with >>> it.). >>> >>> Anyway, I'm beginning to think I'm going about it all wrong, >>> perhaps there's >>> a cleaner way to make this work reliably? Especially in the case >>> where the >>> first connection attempt would hang, and thus can't even initialize >>> the >>> TransportListener, etc.... >>> >>> I'm using AMQ 4.1.1, by the way, with Jencks AMQPool....I've >>> modified the >>> ActiveMQConnectionFactory to use a setTransportListener method >>> (basically >>> copied the same model as was done for AMQ 5.X).... >>> >>> Finally, what is the reason for not allowing the transport to cause a >>> transport failure exception, if all configured failover uri's fail, >>> but >>> still have it be self-recovering if a broker becomes available? >>> >>> Jason >>> >>> What approaches have others tried? >>> -- >>> View this message in context: http://www.nabble.com/How-to-use- >>> TransportListener-with-FailoverTransport-tf4824542s2354.html#a13803554 >>> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >>> >> >> >> > > -- View this message in context: http://www.nabble.com/How-to-use-TransportListener-with-FailoverTransport-tp13803554s2354p15328197.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.