I ran into this issue as well on <= 4.0.2. I never tested it against 4.1. The FailoverTransport doesn't shutdown if it is disconnected at the time of the shutdown.
I believe that the root cause is in the FailoverTransport.oneway(Command command) function which will hold onto the command and keep trying to reconnect until the message is sent or the transport is disposed. I applied a local patch that seems to solve the problem. Note that I've only tested the patch against 4.0.2. Specifically, I early return from the oneway function if the command is ShutdownInfo and the connectedTransport is null. This seems to solve the problem in that I get clean shutdowns on the client when failover is true and the client is presently disconnected. Does this seem like a reasonable patch? Should I create a JIRA with this info? -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 12, 2006 4:46 AM To: activemq-users@geronimo.apache.org Subject: Re: failover mode and client shutdown There could be a bug relating to closes with the failover transport possibly, but the ActiveMQConnection does wait up to the closeTimeout for a close to succeed before shutting down - so you could try reduce the timeout. http://incubator.apache.org/activemq/maven/activemq-core/apidocs/org/apa che/activemq/ActiveMQConnection.html#setCloseTimeout(int) On 12/12/06, Keith Irwin <[EMAIL PROTECTED]> wrote: > Folks-- > > When we have clients running and we take down AMQ (<= 4.1.0), then > attempt to shutdown the clients with Control-C (rather than kill the > JVM with a -9), the clients won't shut down. It's as if a "close" on > the failover connection never reaches the amq client classes. > > I note that in the 4.1.0 release notes, this issue is referenced, and > the advice is to set the maxReconnectAttempts (or similar) property to > something non-zero. > > The problem is that we don't want there to be a max number of > attempts. Unless we specifically want to take down the client (say, > for an apt-get package upgrade), we want it to keep on trying forever. > > SO, my question: Is there an architectural reason for not being able > to close a failover connection if AMQ is down? > > If it isn't impossible due to tradeoffs elsewhere in the code base, we > might be willing to submit a patch to fix the issue. > > Our only other recourse is to attempt to close the connections in > separate threads, then timeout those threads after a while and fall > out the end of the java process. > > For instance: > > Thread th = new Thread(new Runnable() { > public void run() { > connection.close(); > } > }); > th.start(); > > // give up after 2 seconds > Thread.currentThread().join(2000); > > I guess this is do-able, but it seems, you know, some how, well, wrong. > > So, is it worth investigating a patch to AMQ? > > Keith > -- James ------- http://radio.weblogs.com/0112098/
