You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Florent BENOIT (JIRA)" <ji...@apache.org> on 2012/12/13 14:22:12 UTC

[jira] [Commented] (FELIX-3715) ResolverImpl is not thread safe

    [ https://issues.apache.org/jira/browse/FELIX-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531002#comment-13531002 ] 

Florent BENOIT commented on FELIX-3715:
---------------------------------------

In my tests this commit fixed the problem of Thread safe
                
> ResolverImpl is not thread safe
> -------------------------------
>
>                 Key: FELIX-3715
>                 URL: https://issues.apache.org/jira/browse/FELIX-3715
>             Project: Felix
>          Issue Type: Bug
>          Components: Resolver
>         Environment: All
>            Reporter: Thomas Watson
>            Assignee: Richard S. Hall
>         Attachments: org.apache.felix.resolver.patch
>
>
> The org.apache.felix.resolver.ResolverImpl class has many member fields which keep state for a single resolve operation.  But the resolve methods may be called by multiple threads which means different resolve operations could try to use the same internal state objects leading to very unpredictable behavior.
> Here is a list of the current member fields that hold state:
> m_usesPermutations
> m_importPermutations
> m_packageSourcesCache
> I think we should introduce contextual class that can be used to store these state objects as well as the ResolveContext used for a particular resolve operation.  This contextual object (I suggest calling it something like ResolveOperation) would be passed around instead of the ResolveContext.
> I think this approach is necessary instead of using thread local variables.  The reason is that a call back to a ResolveContext could initiate another resolve() operation using an unrelated (or sandbox) environment from the current resolve operation.  Using thread locals would not help in cases where nested resolve() operations happen.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira