You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Thomas Watson (JIRA)" <ji...@apache.org> on 2019/07/15 14:24:00 UTC

[jira] [Resolved] (FELIX-6140) possible deadlock in ResolverImpl.EnhancedExecutor.await()

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

Thomas Watson resolved FELIX-6140.
----------------------------------
    Resolution: Fixed
      Assignee: Thomas Watson

> possible deadlock in ResolverImpl.EnhancedExecutor.await()
> ----------------------------------------------------------
>
>                 Key: FELIX-6140
>                 URL: https://issues.apache.org/jira/browse/FELIX-6140
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>    Affects Versions: resolver-2.0.0, resolver-1.16.0
>            Reporter: Thomas Watson
>            Assignee: Thomas Watson
>            Priority: Major
>
> The org.apache.felix.resolver.ResolverImpl.EnhancedExecutor class is used by the ResolverImpl in order to run tasks in parallel during a resolve process.  When there is work that can happen in parallel the resolver will compute a number of tasks and dispatch each task to the executor and then await for all the tasks to complete.  To do this the current code uses an AtomicInteger to count up the number of tasks and then waits for each task to decrement the count back to zero.
> The way the code builds up the tasks recursively leaves it open to incrementing the count and then getting some system failure. For example an OutOfMemoryException, or before OSGi R7 we used to have the executor throw a runtime exception on timeout.
> This can make it such that the count will never reach zero and we end up hanging. 
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=547830 and possible fix that I plan to release soon at https://git.eclipse.org/r/#/c/143026/



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)