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

["Thomas Watson (JIRA)" <ji...@apache.org>]

     [ 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