Hi Simon,
Simon Kaegi schrieb: > Felix, > > do you know if a similar bug should be logged against Equinox. It's > quite likely that we're using a similar approach. Not sure, because the synchronization is an implementation detail of the Felix implementation and I am not sure, whether the Eclipse implementation suffers from this problem .. With respect to the Class.forName() problem, I am also not sure, whether Eclipse uses this. Regards Felix > Thanks. > -Simon > > ----- Original Message ----- From: "Felix Meschberger (JIRA)" > <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, September 29, 2008 10:53 AM > Subject: [jira] Updated: (FELIX-748) Deadlock with class loading and > URLHandlers > > >> >> [ >> 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. >> > >
