You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Chris Hofstaedter <ch...@nmwco.com> on 2007/01/04 16:34:34 UTC

RE: failover mode and client shutdown

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:james.strachan@gmail.com] 
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 <ke...@gmail.com> 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/

RE: failover mode and client shutdown

Posted by Chris Hofstaedter <ch...@nmwco.com>.
Thanks for the feedback - it's in there as AMQ-1116

-----Original Message-----
From: James Strachan [mailto:james.strachan@gmail.com] 
Sent: Thursday, January 04, 2007 10:38 AM
To: activemq-users@geronimo.apache.org
Subject: Re: failover mode and client shutdown

Sounds like a great idea to me :) Please go ahead and submit a jira
with the patch and we'll get it integrated ASAP

On 1/4/07, Chris Hofstaedter <ch...@nmwco.com> wrote:
> 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:james.strachan@gmail.com]
> 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 <ke...@gmail.com> 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/
>


-- 

James
-------
http://radio.weblogs.com/0112098/

Re: failover mode and client shutdown

Posted by James Strachan <ja...@gmail.com>.
Sounds like a great idea to me :) Please go ahead and submit a jira
with the patch and we'll get it integrated ASAP

On 1/4/07, Chris Hofstaedter <ch...@nmwco.com> wrote:
> 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:james.strachan@gmail.com]
> 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 <ke...@gmail.com> 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/
>


-- 

James
-------
http://radio.weblogs.com/0112098/