directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Seelmann (JIRA)" <>
Subject [jira] [Commented] (DIRSERVER-2036) Upgrade EhCache dependency
Date Sun, 28 Dec 2014 14:25:13 GMT


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:
>             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

View raw message