Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <26891436.1172509623936.JavaMail.jira@brutus>
Date: Mon, 26 Feb 2007 09:07:03 -0800 (PST)
From: "james strachan (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Updated: (AMQ-1119) Deadlock in MutexTransport on shutdown
 with high volume of messages
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/activemq/browse/AMQ-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

james strachan updated AMQ-1119:
--------------------------------

    Fix Version/s: 4.1.1

backported to 4.1 branch: 511900

> Deadlock in MutexTransport on shutdown with high volume of messages
> -------------------------------------------------------------------
>
>                 Key: AMQ-1119
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1119
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 4.0, 4.0.1, 4.0.2
>         Environment: Windows XP, demand forwarding, failover == true
>            Reporter: Chris Hofstaedter
>         Assigned To: Rob Davies
>             Fix For: 4.1.1, 4.2.0
>
>
> I ran into a deadlock in the MutextTransport.oneway(Command command) function when processing very high message volume (100% cpu utilization) at the time of a shutdown.  I'm running 4.0.2 on WinXP and within a demand forwarding environment with failover = true.
>  
> I did trap this deadlock in the debugger and it looks like two commands are crossing paths in opposite directions through the MutexTransport. One of the commands is a MessageDispatch and the other is a ShutdownInfo.  Now, when the ShutdownInfo gets through the MutexTransport first, it tries to shutdown the background thread of the TcpTransport.  However, this thread is currently servicing the MessageDispatch and is blocked on the MutexTransport.  Deadlock.
>  
> So, my patch was simply to avoid entering the synchronized(writeMutex) block in the oneway(Command command) function of MutexTransport if
> command.isShutdownInfo() returns true:
>  
> if (command.isShutdownInfo())
>    next.oneway(command);
> else
>    synchronized(writeMutex)  {
>       next.oneway(command);
>    }

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