[ https://issues.apache.org/jira/browse/FELIX-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Watson updated FELIX-3715: --------------------------------- Attachment: org.apache.felix.resolver.patch Here is a possible fix. I added a ResolveSession class to ResolverImpl to hold all the state holding objects. In most cases I pass a ResolveSession around instead of a ResolveContext now. This makes the patch look rather large, but it is because all the lines of code which accessed state holding member variables now has to access the ResolveSession. I added a couple of TODOs about clearing out the state in finally blocks and about checking for multiple cardinality candidates for dynamic resolution. I think both are needed but wanted to call out to the code where I made functional changes for the reviewer of the patch. > 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 > 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