[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] Commented: (AMQ-1116) deadlock when shutting down client
From:       "Brett Humphreys (JIRA)" <jira () apache ! org>
Date:       2009-03-29 1:10:43
Message-ID: 935673514.1238289043610.JavaMail.jira () brutus
[Download RAW message or body]


    [ https://issues.apache.org/activemq/browse/AMQ-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50879#action_50879 \
] 

Brett Humphreys commented on AMQ-1116:
--------------------------------------

Running the same JUnit test as above, 5.2.0 seems to fix this deadlock issue.

> deadlock when shutting down client that is configured with failover=true and is \
>                 presently disconnected from broker
> ------------------------------------------------------------------------------------------------------------------
>  
> Key: AMQ-1116
> URL: https://issues.apache.org/activemq/browse/AMQ-1116
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 4.0.2
> Reporter: Chris Hofstaedter
> Assignee: Rob Davies
> Fix For: 5.1.0
> 
> Attachments: ConnectionPool.java, DemandForwardingBridgeSupport.java, \
> FailoverTransport.java, FailoverTransport.java, FailoverTransport_AMQ-1116.patch 
> 
> 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 <chrish@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/a
> > pa
> > che/activemq/ActiveMQConnection.html#setCloseTimeout(int)
> > 
> > 
> > On 12/12/06, Keith Irwin <keith.irwin@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
> > > 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[prev in list] [next in list] [prev in thread] [next in thread]