Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of karlpauls@gmail.com designates
 74.125.82.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJnwQNgT5OXCOQ_TgCCObXT431WrCDnUVxwvvgCxWT684=bDmA@mail.gmail.com>
References: <7cfe14ae0584436500808f8b93dab2ff@crux.uberspace.de>
 <CAJnwQNgT5OXCOQ_TgCCObXT431WrCDnUVxwvvgCxWT684=bDmA@mail.gmail.com>
From: Karl Pauls <karlpauls@gmail.com>
Date: Mon, 26 May 2014 15:00:16 +0200
Message-ID: 
 <CAJnwQNj8d_8_Lw7MstG8t1vLCFxX1mYV2xJkTt_pM0A2MraBkg@mail.gmail.com>
Subject: Re: Deadlock in URLHandlers when Felix.init and Felix.stop are called
 concurrently
To: "users@felix.apache.org" <users@felix.apache.org>
Content-Type: multipart/alternative; boundary=f46d04138a25602bca04fa4d2a2e

--f46d04138a25602bca04fa4d2a2e
Content-Type: text/plain; charset=UTF-8

I take it back - it seems to be a bug. Can you create a jira issue for it?

regards,

Karl


On Mon, May 26, 2014 at 2:57 PM, Karl Pauls <karlpauls@gmail.com> wrote:

> Are you using the latest felix version?
>
> regards,
>
> Karl
>
>
> On Mon, May 26, 2014 at 2:44 PM, Benjamin Rogge <
> felix-osgi@benjamin-rogge.de> wrote:
>
>> Hello,
>> from time to time we are experiencing a deadlock in the URLHandlers Class
>> in Apache Felix. We are using Felix as an embedded OSGi Container and
>> instantiate the Felix Framework via ServiceLoader and Framework Factory
>> ourselves. The situation is as follows: When Felix.stop and Felix.init are
>> called by different threads, eventually URLHandlers.
>> unregisterFrameworkListsForContextSearch and URLHandlers.registerFrameworkInstance
>> are called by the threads. There are two locks: m_frameworks and the Class
>> Object of URL (URL.class). registerFrameworkInstance tries to aquire
>> m_frameworks first and via the constructor of URLHanders URL.class after
>> that. unregisterFrameworkListsForContextSearch tries to aquire URL.class
>> first and m_frameworks after that. This is a classic deadlock situation.
>> The situation arises in unittests where we frequently start and stop the
>> felix framework.
>>
>> My questions are: Is it valid to call Felix.init after Felix.stop without
>> waiting if the framework actually stopped (since stop is asyncronous)? Or
>> do we have to wait between Felix.init and Felix.stop? Or would you consider
>> this a bug?
>>
>> Cheers and thanks for your support,
>> Benjamin Rogge
>>
>>
>> P.S.: Here is a listing of the stacktraces:
>>
>> Found one Java-level deadlock:
>> =============================
>> "FelixShutdown":
>>   waiting to lock monitor 0x0000000000ff7710 (object 0x00000007ff33e7f0,
>> a java.util.ArrayList),
>>   which is held by "main"
>> "main":
>>   waiting to lock monitor 0x00000000022c4a08 (object 0x0000000783b06b18,
>> a java.lang.Class),
>>   which is held by "FelixShutdown"
>>
>> Java stack information for the threads listed above:
>> ===================================================
>> "FelixShutdown":
>>         at org.apache.felix.framework.URLHandlers.
>> unregisterFrameworkListsForContextSearch(URLHandlers.java:315)
>>         - waiting to lock <0x00000007ff33e7f0> (a java.util.ArrayList)
>>         - locked <0x00000007ff33e840> (a java.util.HashMap)
>>         - locked <0x0000000783b06b18> (a java.lang.Class for java.net.URL)
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:57)
>>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>>         at java.lang.reflect.Method.invoke(Method.java:606)
>>         at org.apache.felix.framework.util.SecureAction.invoke(
>> SecureAction.java:840)
>>         at org.apache.felix.framework.URLHandlers.
>> unregisterFrameworkInstance(URLHandlers.java:635)
>>         at org.apache.felix.framework.URLHandlersActivator.stop(
>> URLHandlersActivator.java:76)
>>         at org.apache.felix.framework.util.SecureAction.
>> stopActivator(SecureAction.java:667)
>>         at org.apache.felix.framework.Felix$SystemBundleActivator.
>> stop(Felix.java:4715)
>>         at org.apache.felix.framework.util.SecureAction.
>> stopActivator(SecureAction.java:667)
>>         at org.apache.felix.framework.Felix.stopBundle(Felix.java:2530)
>>         at org.apache.felix.framework.Felix$2.run(Felix.java:959)
>>         at java.lang.Thread.run(Thread.java:724)
>> "main":
>>         at org.apache.felix.framework.URLHandlers.<init>(
>> URLHandlers.java:150)
>>         - waiting to lock <0x0000000783b06b18> (a java.lang.Class for
>> java.net.URL)
>>         at org.apache.felix.framework.URLHandlers.
>> registerFrameworkInstance(URLHandlers.java:600)
>>         - locked <0x00000007ff33e7f0> (a java.util.ArrayList)
>>         at org.apache.felix.framework.URLHandlersActivator.start(
>> URLHandlersActivator.java:71)
>>         at org.apache.felix.framework.util.SecureAction.
>> startActivator(SecureAction.java:645)
>>         at org.apache.felix.framework.Felix$SystemBundleActivator.
>> start(Felix.java:4634)
>>         at org.apache.felix.framework.util.SecureAction.
>> startActivator(SecureAction.java:645)
>>         at org.apache.felix.framework.Felix.init(Felix.java:783)
>>         // ... Application specific trace
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>


-- 
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

--f46d04138a25602bca04fa4d2a2e--