[
https://issues.apache.org/jira/browse/DIRSERVER-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259649#comment-14259649
]
Stefan Seelmann commented on DIRSERVER-2036:
--------------------------------------------
In newer versions of ehcache the behaviour of CacheManager changed. In 2.4 the
creation of a new net.sf.ehcache.CacheManager always worked. In 2.8 (or an
earlier version) this changed, a cache manager must have a unique name, the
names and instances are tracked in a static map of CacheManager.
Our CacheService wraps the CacheManager. Without the patch a new CacheService
instance always creates a new CacheManager instance which always workes. The
patch changes this behaviour of CacheService a bit, if an instanceId is
provided it may happen that the creation/initialization of CacheService fails,
if another CacheManager with the same name already exists. So I think to keep
the previous behaviour I'd remove the usage of instanceId and always use a new
UUID as cache name. WDYT?
But I see other thing in CacheService which requires discussion: When creating
two CacheSerices with same InstanceLayout, we end up in two cache managers that
share the same disk store path, which is not good.
> Upgrade EhCache dependency
> --------------------------
>
> Key: DIRSERVER-2036
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2036
> Project: Directory ApacheDS
> Issue Type: Improvement
> Reporter: Colm O hEigeartaigh
> Fix For: 2.0.0-M20
>
> Attachments: dirserver-2036.patch
>
>
> Apache DS uses a old version of EhCache. This task is to upgrade to a newer
> version. Since EhCache 2.5.x, it is not permitted to create new CacheManagers
> with the same name. The patch attached to this JIRA works around this by
> associating the instanceId with the CacheManager.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
