Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <514842963.20811269256311713.JavaMail.jira@brutus.apache.org>
Date: Mon, 22 Mar 2010 11:11:51 +0000 (UTC)
From: "Rob Davies (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Commented: (AMQ-2645) Deadlock during FailoverTransport
 interruption
In-Reply-To: <2096443773.10171268232348451.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/activemq/browse/AMQ-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58374#action_58374 ] 

Rob Davies commented on AMQ-2645:
---------------------------------

There's changes to the transport interface to support this - so its not possible to put into 5.3.1

> Deadlock during FailoverTransport interruption
> ----------------------------------------------
>
>                 Key: AMQ-2645
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2645
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.3.1
>            Reporter: Dariusz Szablinski
>            Assignee: Rob Davies
>            Priority: Blocker
>             Fix For: 5.4.0
>
>         Attachments: screenshot-1.JPG, screenshot-2.JPG
>
>
> Here is my scenario:
> 1)	Two AMQ servers setup with shared persistence storage (replicated message store)
> 2)	Single client constantly sends/receives small messages to/form one queue and uses single Connection with failover transport configured. The client code you can find here: AMQ-2512.
> 3)	After pushing several messages, shutdown active AMQ node - second one will kick in; client will successfully reconnect to this new active node; however it won't be able to receive any message out of the queue. Following warning is also generated by the client every 15s: "WARNING: dispatch paused, waiting for outstanding dispatch interruption processing (20) to complete..".
> During debugging I've found that code which is supposed to clean messages during reconnection await for MessageDispatchChannel mutex owned by one of the session threads (screenshot-1). This session thread, from the other hand, is in the middle of send operation and waits for server's response. In result messages dispatch awaits infinitely on CountDownLatch which is supposed to be decremented by the deadlocked messages cleaning code (screenshot-2).
> This occurs in the latest 5.3.1-SNAPSHOT as well as in 5.3.0-fuse-01-00 version.

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