Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <1389632852.1222700025476.JavaMail.jira@brutus>
Date: Mon, 29 Sep 2008 07:53:45 -0700 (PDT)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Updated: (FELIX-748) Deadlock with class loading and
 URLHandlers
In-Reply-To: <915558742.1222700025188.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Felix Meschberger updated FELIX-748:
------------------------------------

    Attachment: FELIX-748-deadlock.txt

Here is the full stacktrace of the three deadlocking threads.

> Deadlock with class loading and URLHandlers
> -------------------------------------------
>
>                 Key: FELIX-748
>                 URL: https://issues.apache.org/jira/browse/FELIX-748
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: felix-1.0.4
>            Reporter: Felix Meschberger
>         Attachments: FELIX-748-deadlock.txt
>
>
> We have a tricky dead lock issue involving Java ClassLoaders and the Felix framework URLHandlers class. We have two web apps: An Apache Sling web app using Felix as its framework and a second Web App providing a JCR repository.
> While starting up, someone is accessing the JCR repository web app which causes a JSP compilation. This involves class loading and calls into the Felix URLHandlers to create some URL.
> The deadlock description is:
> Found one Java-level deadlock:
> =============================
> "SimpleQuartzScheduler_QuartzSchedulerThread":
>   waiting to lock monitor 0x0aaa6634 (object 0x03256ac0, a java.net.URLClassLoader),
>   which is held by "SCR Component Actor"
> "SCR Component Actor":
>   waiting to lock monitor 0x0aaa65cc (object 0x02ebba58, a java.net.URLClassLoader),
>   which is held by "127.0.0.1 [1222693412656] GET /crx/browser/index.jsp HTTP/1.1"
> "127.0.0.1 [1222693412656] GET /crx/browser/index.jsp HTTP/1.1":
>   waiting to lock monitor 0x0aaa6634 (object 0x03256ac0, a java.net.URLClassLoader),
>   which is held by "SCR Component Actor"
> Looking at the code, it seems, that the URLHandlers.createURLStreamHandler class is using a synchronized blog which looks too big. In addition it uses the SecureAction.forName method, which in turn uses Class.forName, which has its issues, too.
> So maybe the URLHandlers.createURLStreamHandler method should employ a different synchronization mechanism so as to avoid deadlocks through classloaders.

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