[
https://issues.apache.org/jira/browse/FELIX-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866464#action_12866464
]
Jed Wesley-Smith commented on FELIX-2332:
-----------------------------------------
Karl, there are a couple of things I am concerned about with your commit.
Firstly there is partial visibility of changes, specifically in
_removeExtensions(Object). It now completely clears the m_extensionsCache and
then calls _add(String, Bundle) to add the old ones in one by one. As the
openConnection(URL) method is no longer synchronised it can see the
m_extensionsCache in a partially updated state. It would be better to write the
m_extensionsCache at the end of the method once m_extensions is completely
updated. This would also remove any intermediate array creation in this case.
Obviously addExtension(Object source, Bundle extension) would also need to
explicitly write the m_extensionsCache as well. This partial visibility issue
could lead to some spurious and very hard to reproduce IOExceptions.
Second is a small point, the rewritten openConnection method uses Java5 syntax
(foreach loop), but the m_extensionsCache write in _add uses the old 1.4
explicit cast of the array, unnecessary in Java5. I don't know if Felix3 is
Java5 or not, or if it is whether there a policy for using Java5 features.
> Lots of contention on ExtensionManager.openConnection(URL)
> ----------------------------------------------------------
>
> Key: FELIX-2332
> URL: https://issues.apache.org/jira/browse/FELIX-2332
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-2.0.5
> Reporter: Jed Wesley-Smith
> Assignee: Karl Pauls
> Fix For: framework-3.0.0
>
> Attachments: ExtensionManager.java.patch
>
>
> This method is synchronized, apparently to protect is the iteration through
> the m_extensions list. We have seen significant blocking in our applications
> as this lock encompasses the call to URL.openConnection as well.
> As this list is rarely changed, a copy-on-write structure would be more
> appropriate, but at the very least the, only holding the lock during the
> iteration would be far preferable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
