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-tf4824542s2354.html#a13808084 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
