[
https://issues.apache.org/jira/browse/STANBOL-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964964#comment-14964964
]
Rupert Westenthaler edited comment on STANBOL-1443 at 10/20/15 10:57 AM:
-------------------------------------------------------------------------
fixed with http://svn.apache.org/viewvc?rev=1709397&view=rev in 0.12.1 and
http://svn.apache.org/viewvc?rev=1709524&view=rev in trunk
was (Author: rwesten):
fixed with http://svn.apache.org/viewvc?rev=1709397&view=rev in 0.12.1 and
http://svn.apache.org/viewvc?rev=1709525&view=rev in trunk
> FastLRUCacheManager of the FST Linking Engine is not thread save
> ----------------------------------------------------------------
>
> Key: STANBOL-1443
> URL: https://issues.apache.org/jira/browse/STANBOL-1443
> Project: Stanbol
> Issue Type: Bug
> Components: Enhancement Engines
> Affects Versions: 0.12.0
> Reporter: Rupert Westenthaler
> Assignee: Rupert Westenthaler
> Fix For: 1.0.0, 0.12.1
>
>
> The {{FastLRUCacheManager}} is the implementation of the
> {{EntityCacheManager}}. The EntityCacheManager interface uses the
> {{o.a.solr.util.RefCounted}} for getting the EntityCache object.
> However the management of the RefCount of the {{FastLRUCacheManager}}
> implementation is not thread save. So under high load the actual ref count
> can get wrong values. Based on logs I observed negative values (resulting in
> close operations in the Cache) and also very high values (potentially
> resulting in Caches not being correctly garbage collected).
> To fix this issue the {{FastLRUCacheManager.getCache(Object version)}} needs
> to be implemented in a thread save manner. Also the {{#close()}} method needs
> to be thread save.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
