You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2017/04/28 08:41:04 UTC
[jira] [Closed] (FELIX-5615) Global lock in
BaseMethod.NotResolved::resolve method can cause deadlock
[ https://issues.apache.org/jira/browse/FELIX-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler closed FELIX-5615.
-----------------------------------
> Global lock in BaseMethod.NotResolved::resolve method can cause deadlock
> ------------------------------------------------------------------------
>
> Key: FELIX-5615
> URL: https://issues.apache.org/jira/browse/FELIX-5615
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Reporter: Thomas Watson
> Assignee: Thomas Watson
> Fix For: scr-2.0.10
>
>
> See eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=515215
> org.apache.felix.scr.impl.inject.BaseMethod.NotResolved has a single instance which is held by the static field NotResolved.INSTANCE
> This means that the synchronized method NotResolved::resolve holds the global lock on this NotResolved.INSTANCE object. It is unclear why this complete method needs to be synchronized. But is is also unclear why it has to be a global lock also. Is this by design? or a consequence of some refactoring that made this method act on a global lock?
> This is causing issues because while calling BaseMethod::findMethod reflection is done which can then trigger additional class loads. These can then result in lazy activation to be triggered. There is a whole set of deadlock situations that could happen during lazy activation while this global lock is being held.
> I have not studied the code in detail, but it appears BaseMethod:findMethod is stateless and it is unclear why we need to hold a lock between calls to BaseMethod::findMethod and BaseMethod::setMethod (let alone a global lock).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)