[ 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