[
https://issues.apache.org/jira/browse/FELIX-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-3715.
------------------------------------
Resolution: Fixed
Assignee: Richard S. Hall
I've applied the patch and deployed a snapshot. Please close this issue if you
are satisfied. Thanks.
> 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
