Uploaded image for project: 'Directory ApacheDS'
  1. Directory ApacheDS
  2. DIRSERVER-2036

Upgrade EhCache dependency

        Details

        • Type: Improvement
        • Status: Resolved
        • Priority: Major
        • Resolution: Fixed
        • Affects Version/s: None
        • Fix Version/s: 2.0.0-M20
        • Component/s: None
        • Labels:
          None

          Description


          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.

          1. Text File
            dirserver-2036.patch
            7 kB
            Colm O hEigeartaigh
          2. File
            dirserver-2036.patch.2
            8 kB
            Colm O hEigeartaigh

            Issue Links

            is duplicated by

            Task - A task that needs to be done. DIRSERVER-2040 Upgrade ehcache

            • Major - Major loss of function.
            • Closed

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              coheigea Colm O hEigeartaigh added a comment -

              A patch for this issue.

              Colm.

              Show
              coheigea Colm O hEigeartaigh added a comment - A patch for this issue. Colm.
              Hide
              Permalink
              seelmann Stefan Seelmann added a comment -

              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.

              Show
              seelmann Stefan Seelmann added a comment - 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.
              Hide
              Permalink
              coheigea Colm O hEigeartaigh added a comment -

              Hi Stefan,

              See a revised patch for this issue which addresses your two concerns. It uses the UUID in all cases as the CacheManager name. Secondly, it appends the CacheManager name (the UUID) to the diskstore path. So for example, if I run the tests I end up with cache files stored in something like:

              /tmp/a2985259-73d5-471e-ad19-e4626c8ff2d8

              Colm.

              Show
              coheigea Colm O hEigeartaigh added a comment - Hi Stefan, See a revised patch for this issue which addresses your two concerns. It uses the UUID in all cases as the CacheManager name. Secondly, it appends the CacheManager name (the UUID) to the diskstore path. So for example, if I run the tests I end up with cache files stored in something like: /tmp/a2985259-73d5-471e-ad19-e4626c8ff2d8 Colm.
              Hide
              Permalink
              seelmann Stefan Seelmann added a comment -

              Thanks Colm, the patch looks good to me, feel free to commit.

              Show
              seelmann Stefan Seelmann added a comment - Thanks Colm, the patch looks good to me, feel free to commit.

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  coheigea Colm O hEigeartaigh
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Development