[
https://issues.apache.org/jira/browse/FELIX-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Carroll closed FELIX-5976.
----------------------------------
Resolution: Not A Problem
Marking our class loader as parallel enabled solved the issue
> Deadlock can occur when loading class in Permissions.java
> ---------------------------------------------------------
>
> Key: FELIX-5976
> URL: https://issues.apache.org/jira/browse/FELIX-5976
> Project: Felix
> Issue Type: Bug
> Environment: Centos, Apache Catalina
> Reporter: Timothy Carroll
> Priority: Blocker
>
> My company is attempting to use Felix Framework Security, but we are running
> into a race condition that can lead to thread deadlock. The Felix Security
> class causing the deadlock is
> {{org.apache.felix.framework.security.util.Permissions.java}}
> We're using Felix Security v2.4.0 in a Tomcat Catalina app server v8.5.34. We
> believe the issue could occur in the latest Felix Security version as well.
> The line of code in questions is line 530 where the
> {{Permissions.createPermission}} method attempts to load a class.
> We found that the deadlock occurs if the {{loadClass}} method ends up using
> the root Catalina class loader, {{WebappClassLoaderBase}}. Essentially, we
> have a case where we use {{javax.xml}} to serialize or deserialize something
> in an OSGI bundle which results in a call to
> {{org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntries}},
> which is a largely synchronized method. While attempting to get the entries,
> we run into a permissions check that needs to obtain the lock managed by
> {{WebappClassLoaderBase}} because of line 530.
> At the same time, we run into a reversed lock order from some older,
> pre-existing code that is not directly controlled by us. Essentially, our
> servlet filters attempt to load a class, obtaining the lock on
> {{WebappClassLoaderBase}}. The class loader (not in our code) is doing
> something, however, that needs to load archive entries through OSGI which
> runs into the lock on
> {{org.apache.catalina.webresources.AbstractSingleArchiveResourceSet.getArchiveEntries}}.
> Thus, we have a deadlock.
> Since the pre-existing code that obtains the locks in the order
> {{WebappClassLoaderBase}} > {{AbstractSingleArchiveResourceSet}} is much more
> opaque and also preexisting in our codebase, we're hoping that we can figure
> out how to avoid the check on line 530 of {{Permissions}}. It seems like it
> could be unnecessary, but we would love some assistance from Karl or anyone
> else familiar with the security framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
