[MGNLCACHE-32] Upgrade Ehcache to the latest (2.10.0) Created: 28/Jan/11  Updated: 15/Dec/16  Resolved: 06/Feb/15

Status: Closed
Project: Cache Modules
Component/s: None
Affects Version/s: None
Fix Version/s: 5.4

Type: Improvement Priority: Major
Reporter: Tobias Mattsson Assignee: Roman Kovařík
Resolution: Fixed Votes: 3
Labels: architecture, m2, support
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLCACHE-66 Explicitly prevent an Ehcache named "... Closed
causality
is causing MGNLOPENSOCIAL-2 Remove workarounds in OpenSocials dep... Closed
is causing MGNLCACHE-82 Runtime reconfiguration without killi... Closed
relation
is related to MGNLCACHE-55 Caching arbitrary objects Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLCACHE-61 Update default ehcache configuration Sub-task Closed Magnolia International  
MGNLCACHE-60 Revise EhCacheFactory Sub-task Closed Roman Kovařík  
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Date of First Response:

 Description   

We currently use ehache version 1.5, released in 2008. On more than one occasion i've talked to users having problems integrating other technologies due to version conflict with this outdated dependency.

We should upgrade to the latest version.

There's also been at lot of improvements that we would benefit from, especially the release notes for version 1.6 claims: "This release introduces a new high performance cache core, which is two orders of magnitude faster."



 Comments   
Comment by Daniel Lipp [ 04/Feb/11 ]

Shindig 2.0.2 already uses ehcache 2.2.0 - would simplify things if we could directly use that version.

Comment by Zdenek Skodik [ 07/May/13 ]

Updating to the latest ehcache 2.7 involves also slf4j update from current 1.6.4 (as done because of MAGNOLIA-3979) to 1.6.6 the new version depends on. The update will also leightweight our webapps by two other jars we ship at the moment:

[INFO] |  +- backport-util-concurrent:backport-util-concurrent:jar:3.1:compile
[INFO] |  \- net.sf.jsr107cache:jsr107cache:jar:1.0:compile
Comment by Magnolia International [ 14/Mar/14 ]

MGNLCACHE-32 and MGNLCACHE-55 could perhaps be tackled together; I don't think there is an actual dependency between the 2 changes, but we should definitely look at both issues to make we're not going to make one or the other more difficult to implement.

Comment by Magnolia International [ 04/Jun/14 ]

Pushed to feature/cache-arbitrary-objects branch. (commit ba9ea02)
See TODOs in MGNLCACHE-55 to verify we use the correct APIs or if there are preferred replacements.

Comment by Magnolia International [ 04/Aug/14 ]

magnolia_main's parent pom still has a dependencyManagement entry for ehcache. Removing it.

Comment by Magnolia International [ 13/Aug/14 ]

Pushed to feature/cache-arbitrary-objects-2 branch

Comment by Jan Haderka [ 08/Dec/14 ]

Not done until subtasks are done too ... can you update their progress to reflect reality? ... and finish them if not done yet?

Comment by Evzen Fochr [ 06/Feb/15 ]

for QA of raised EH cache version

Generated at Sun Feb 11 23:51:32 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.