[
https://issues.apache.org/jira/browse/TRINIDAD-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764803#action_12764803
]
Jeanne Waldman commented on TRINIDAD-1594:
------------------------------------------
This is related to TRINIDAD-1460 implement FileSystemStyleCache code review
comments.
In that JIRA issue, comments include "_cache and _entryCache should probably be
ConcurrentHashMaps." which this patch will take care of.
> FileSystemStyleCache doesn't scale due to over-synchronization
> --------------------------------------------------------------
>
> Key: TRINIDAD-1594
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1594
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Skinning
> Affects Versions: 1.2.11-core, 1.2.12-core
> Environment: All
> Reporter: Blake Sullivan
> Attachments: JIRA_1594_1_2_12_2.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> FileSystemStyleCache doesn't scale under load due to the use of Hashtables
> for _cache and _entryCache fields. Since Hashtables are implicitly
> synchronized and these objects are shared across the entire application.
> Access to these objects is shared across all users. In addition, there is
> synchronization in the remove case when modification checking is enabled in
> _getEntry(). The best fix is to replace these with ConcurrentMaps (which
> also support an atomic remove to handle the _getEntry() case)
> Other issues:
> _getDerivationKey() uses a Vector as a temporary object for no apparent
> reason (the implicit synchronization isn't needed in this case since the
> Vector never escapes the function)
> The _resolver is lazily initialized but can never change, so it is better to
> initialize this field in the constructor so that it can be made final
> _sourceFile and _baseName never change, so they should be final.
> Note that even with these fixes, there are still further synchronization
> issues with this class. However, the biggest scalability issue is that
> _getEntry() still contains a synchronized block in order to deal with the
> case where modification checking is enabled. There are also some safe
> publication problems, but the most important issue in the future would be
> getting rid of the synchronization, at least when modification checking is off
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
