You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2010/09/14 01:01:32 UTC

[jira] Created: (FELIX-2597) Deadlock during delivery of resolved event

Deadlock during delivery of resolved event
------------------------------------------

                 Key: FELIX-2597
                 URL: https://issues.apache.org/jira/browse/FELIX-2597
             Project: Felix
          Issue Type: Improvement
          Components: Framework
    Affects Versions: framework-3.0.2
            Reporter: Richard S. Hall
            Assignee: Richard S. Hall
            Priority: Minor
             Fix For: framework-3.2.0


When the framework resolves a bundle, it fires the RESOLVED event to synchronous bundle listeners while holding the global lock. This caused a deadlock in a specific scenario where two threads T1 and T2 were racing to resolve bundled B1 and B2, respectively. T1 was resolving a dynamic import for B2 which started from a loadClassInternal() call from the JVM which locks B2's class loader. T1 lost the race for the global lock and had to wait for T2 to do its resolve of B2. T2 ended up firing a RESOLVED event to B1. In B1's callback method, a loadClassInternal() was triggered by T2 when it accessed some static, which caused it to deadlock when the JRE tried to lock the B1's class loader on T2, which was already held by T1.

This issue is actually related to the JVM being too aggressively in its locking of class loaders:

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071

Regardless, we might be able to loosen this up a little bit by not holding the global lock at all. This might slightly violate the definition of synchronous bundle listener, since the state could change, but at least it will still be delivered synchronously on the instigating thread.

More information here:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=13329



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

[jira] Closed: (FELIX-2597) Deadlock during delivery of resolved event

Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard S. Hall closed FELIX-2597.
----------------------------------

    Resolution: Fixed

I've committed a patch for this.

> Deadlock during delivery of resolved event
> ------------------------------------------
>
>                 Key: FELIX-2597
>                 URL: https://issues.apache.org/jira/browse/FELIX-2597
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>    Affects Versions: framework-3.0.2
>            Reporter: Richard S. Hall
>            Assignee: Richard S. Hall
>            Priority: Minor
>             Fix For: framework-3.0.3
>
>
> When the framework resolves a bundle, it fires the RESOLVED event to synchronous bundle listeners while holding the global lock. This caused a deadlock in a specific scenario where two threads T1 and T2 were racing to resolve bundles B1 and B2, respectively. T1 was resolving a dynamic import for B1 which started from a loadClassInternal() call from the JVM which locks B1's class loader. T1 lost the race for the global lock and had to wait for T2 to do its resolve of B2. T2 resolved B2 and ended up firing a RESOLVED event to B1. In B1's callback method, a loadClassInternal() was triggered by T2 when it accessed some static, which caused it to deadlock when the JRE tried to lock the B1's class loader on T2, which was already held by T1.
> This issue is actually related to the JVM being too aggressively in its locking of class loaders:
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071
> Regardless, we might be able to loosen this up a little bit by not holding the global lock at all. This might slightly violate the definition of synchronous bundle listener, since the state could change, but at least it will still be delivered synchronously on the instigating thread.
> More information here:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=13329

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

[jira] Updated: (FELIX-2597) Deadlock during delivery of resolved event

Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard S. Hall updated FELIX-2597:
-----------------------------------

    Fix Version/s: framework-3.0.3
                       (was: framework-3.2.0)

> Deadlock during delivery of resolved event
> ------------------------------------------
>
>                 Key: FELIX-2597
>                 URL: https://issues.apache.org/jira/browse/FELIX-2597
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>    Affects Versions: framework-3.0.2
>            Reporter: Richard S. Hall
>            Assignee: Richard S. Hall
>            Priority: Minor
>             Fix For: framework-3.0.3
>
>
> When the framework resolves a bundle, it fires the RESOLVED event to synchronous bundle listeners while holding the global lock. This caused a deadlock in a specific scenario where two threads T1 and T2 were racing to resolve bundles B1 and B2, respectively. T1 was resolving a dynamic import for B1 which started from a loadClassInternal() call from the JVM which locks B1's class loader. T1 lost the race for the global lock and had to wait for T2 to do its resolve of B2. T2 resolved B2 and ended up firing a RESOLVED event to B1. In B1's callback method, a loadClassInternal() was triggered by T2 when it accessed some static, which caused it to deadlock when the JRE tried to lock the B1's class loader on T2, which was already held by T1.
> This issue is actually related to the JVM being too aggressively in its locking of class loaders:
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071
> Regardless, we might be able to loosen this up a little bit by not holding the global lock at all. This might slightly violate the definition of synchronous bundle listener, since the state could change, but at least it will still be delivered synchronously on the instigating thread.
> More information here:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=13329

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

[jira] Updated: (FELIX-2597) Deadlock during delivery of resolved event

Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard S. Hall updated FELIX-2597:
-----------------------------------

    Description: 
When the framework resolves a bundle, it fires the RESOLVED event to synchronous bundle listeners while holding the global lock. This caused a deadlock in a specific scenario where two threads T1 and T2 were racing to resolve bundles B1 and B2, respectively. T1 was resolving a dynamic import for B1 which started from a loadClassInternal() call from the JVM which locks B1's class loader. T1 lost the race for the global lock and had to wait for T2 to do its resolve of B2. T2 resolved B2 and ended up firing a RESOLVED event to B1. In B1's callback method, a loadClassInternal() was triggered by T2 when it accessed some static, which caused it to deadlock when the JRE tried to lock the B1's class loader on T2, which was already held by T1.

This issue is actually related to the JVM being too aggressively in its locking of class loaders:

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071

Regardless, we might be able to loosen this up a little bit by not holding the global lock at all. This might slightly violate the definition of synchronous bundle listener, since the state could change, but at least it will still be delivered synchronously on the instigating thread.

More information here:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=13329



  was:
When the framework resolves a bundle, it fires the RESOLVED event to synchronous bundle listeners while holding the global lock. This caused a deadlock in a specific scenario where two threads T1 and T2 were racing to resolve bundled B1 and B2, respectively. T1 was resolving a dynamic import for B2 which started from a loadClassInternal() call from the JVM which locks B2's class loader. T1 lost the race for the global lock and had to wait for T2 to do its resolve of B2. T2 ended up firing a RESOLVED event to B1. In B1's callback method, a loadClassInternal() was triggered by T2 when it accessed some static, which caused it to deadlock when the JRE tried to lock the B1's class loader on T2, which was already held by T1.

This issue is actually related to the JVM being too aggressively in its locking of class loaders:

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071

Regardless, we might be able to loosen this up a little bit by not holding the global lock at all. This might slightly violate the definition of synchronous bundle listener, since the state could change, but at least it will still be delivered synchronously on the instigating thread.

More information here:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=13329




> Deadlock during delivery of resolved event
> ------------------------------------------
>
>                 Key: FELIX-2597
>                 URL: https://issues.apache.org/jira/browse/FELIX-2597
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework
>    Affects Versions: framework-3.0.2
>            Reporter: Richard S. Hall
>            Assignee: Richard S. Hall
>            Priority: Minor
>             Fix For: framework-3.2.0
>
>
> When the framework resolves a bundle, it fires the RESOLVED event to synchronous bundle listeners while holding the global lock. This caused a deadlock in a specific scenario where two threads T1 and T2 were racing to resolve bundles B1 and B2, respectively. T1 was resolving a dynamic import for B1 which started from a loadClassInternal() call from the JVM which locks B1's class loader. T1 lost the race for the global lock and had to wait for T2 to do its resolve of B2. T2 resolved B2 and ended up firing a RESOLVED event to B1. In B1's callback method, a loadClassInternal() was triggered by T2 when it accessed some static, which caused it to deadlock when the JRE tried to lock the B1's class loader on T2, which was already held by T1.
> This issue is actually related to the JVM being too aggressively in its locking of class loaders:
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071
> Regardless, we might be able to loosen this up a little bit by not holding the global lock at all. This might slightly violate the definition of synchronous bundle listener, since the state could change, but at least it will still be delivered synchronously on the instigating thread.
> More information here:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=13329

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