Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Wed, 13 Apr 2011 17:12:05 +0000 (UTC)
From: "Richard S. Hall (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: 
 <626813480.55561.1302714725697.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <162360137.54688.1302688805680.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (FELIX-2913) Deadlock in some case
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/FELIX-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019437#comment-13019437 ] 

Richard S. Hall commented on FELIX-2913:
----------------------------------------

I guess that makes some sense. In 3.2.0 we modified the code for adding listeners to acquire the bundle's state lock, otherwise there was a race condition where listeners could be added after a bundle was stopped. We'll have to think about this a little bit to see if there is another way to handle the situation.

> Deadlock in some case
> ---------------------
>
>                 Key: FELIX-2913
>                 URL: https://issues.apache.org/jira/browse/FELIX-2913
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: framework-3.2.0
>         Environment: mac os x
>            Reporter: Stephane Chomat
>            Priority: Critical
>             Fix For: framework-4.0.0
>
>
> I met a deadlock problem with felix 3.2.0.
> There is no problem with felix 3.0.9
> A thread waits on m_bundleLockObject in method acquireBundleLock and m_globalLockThread is null and m_globalLockCount equals to 0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira