[MAGNOLIA-636] Refactored pluggable, manageable cache handling Created: 13/Feb/06  Updated: 23/Jan/13  Resolved: 05/Nov/07

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 2.1.3
Fix Version/s: 3.5 RC1

Type: Improvement Priority: Minor
Reporter: Andreas Brenk Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File cache.patch     File cache.tar.gz     XML File config.server.cache.xml    
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)
Date of First Response:

 Description   

I've refactored the CacheHandler to use a pluggable implementation. One being the existing filesystem based one and another ehcache-based. It optionally keeps statistics about cache hits and misses is JMX manageable. It's also completely configurable using the existing cache config node in the repository. Cache thread usage is configurable using the util.concurrent Executors (one Thread for each request as it is now or a ThreadPool, or a single Thread, ...). The ehcache implementation has configurable memory and disk cache size and lifetime parameters and can use sophisticated expirations strategies like "first in first out" or "least recently used".

The code is currently for Magnolia 2.1.3.

What is the best way to get this integrated? And what is the interest?



 Comments   
Comment by Markus Strickler [ 13/Feb/06 ]

Hi-
great to hear. Maybe you can create a patch against the 2.1 branch, zip it up and attach it to this issue?
On a side node, has anone tried OSCache integration? I would allow for setting chache parameters in the JSP templates, and nifty things like caching per session.

Comment by Sameer Charles [ 13/Feb/06 ]

Great!
yeah would be nice if you can attach your work with small description. I would like to look at it and if we all agree will implement it on the trunk.

thanks

Comment by Andreas Brenk [ 13/Feb/06 ]

This is a patch against the 2.1 branch, a tarball with the new files and an export of the extended cache configuration (you probably have to correct the domain property - it must be set). I hope nothing is missing.

There are still some minor todos which I'm going to address this week. I'll also put together some documentation. What would be the best way? xdocs/advanced/cache.xml?

Comment by Andreas Brenk [ 13/Feb/06 ]

I did consider using the OSCache taglib but then decided that I do not want my template developers to mess with the cache settings... Take a look at Cache and ehcache.CacheImpl. It should be pretty easy to put together an OSCache implementation.

I forgot the mention that the attached code should be run on J2SE 1.5 and Tomcat 5.5.

Would it make sense to move the code to info.magnolia.module.cache and implement the Module interface? This would remove the dependency on ConfigLoader and standardize the lifecycle, right?

Comment by Alexandru Popescu [ 14/Feb/06 ]

Andreas this would be a great addition to Magnolia. So, there are a few things that I find important: dependency upon JDK1.5: Magnolia should work on previous JDKs too, so if this patch can be adapted so it is not requiring JDK1.5 it would be great. I assume that the next "limitation" Tomcat 5.5 comes from JDK1.5 dependency, and not because of something else.

./alex

.w( the_mindstorm )p.

Comment by Andreas Brenk [ 14/Feb/06 ]

Alex, it is not my intention to create a (runtime) dependency on JDK 1.5, the JMX part is already seperated from the main classes. This should be kept strictly optional. If we want to avoid the compile time dependency on 1.5 we need a seperate source tree I guess.

Comment by Philipp Bracher [ 09/Mar/06 ]

Can you use the FactoryUtil to instantiate the CashHandler, so that we can define the implementation in the magnolia.properties?

This will facilitate moving to Spring later.

Comment by Fabrizio Giustina [ 10/Mar/06 ]

committed to trunk.

I already created a new magnolia-cache module, but the code is actually in core.
todo:

  • add jmx dependency (needed to compile on jdk 1.4)
  • implement the module interface and remove dependencies from config
  • move the code to the appropriate module
  • change logging code from log4j to slf4j
  • documentation (apt format, in magnolia-cache/src/site/apt)
  • make it work without requiring a configured domain
  • ?

thanks for your contribution Andreas, looks great! Let me know if you want to take a look at what is now in svn trunk and if you can help with any of the above tasks.
fabrizio

Comment by Fabrizio Giustina [ 11/Mar/06 ]

done:

  • add jmx dependency (needed to compile on jdk 1.4)
  • implement the module interface and remove dependencies from config
  • move the code to the appropriate module
  • change logging code from log4j to slf4j
  • make it work without requiring a configured domain (more or less)

the new cache module is almost complete, but at the moment it doesn't work due to the changes in authentication in svn trunk.

What I would like to do is removing the need for a separate thread/request at all, and simply caching the result of the CURRENT request by gathering the response result from the filter. This makes everything simpler and reduce the number of requests that need to be handled by Magnolia... the new thread management stuff could beremoved by choosing this path. If I remember well OSCache has a similar working http filter.
Thoughts?

Comment by Fabrizio Giustina [ 12/Mar/06 ]

I just committed a large refactoring that removes the need for a separate cache request by fetching the request result from the filter. This kills all the authentication problems.
It's more or less working now, but APIs need to be cleaned up a lot (sorry for the mess, the refactoring was very large and now many methods looks useless or duplicated).
The default implementation configured is now the "simple" one (like magnolia 2.x but with a different directory structure, gzipped pages are saved with the .gzip extension - more friendly to debug).

other todos:

  • the ehcache implementation still lacks support for compressed entries
  • check/setup last modified time and check all the headers
  • implements flush in simple cache (be sure to not delete wrong directories if somebody has configured an incorrect path!)
  • make CacheManager configurable
  • let user override the isCacheable() and cache key generation methods (and CacheKey implementation). Check how path is created in simple cache (now cache key = file path, but we should not rely on that)

Give it look and report your impressions, please

Comment by Magnolia International [ 10/Oct/07 ]

status, feedback, comments ?
how is the current state related to Andreas' patch? Is it derived from it or not ?

Comment by Fabrizio Giustina [ 05/Nov/07 ]

Last changes committed to svn: ehcache now handles gzipped entries too and observation is moved from simple cache to the default cache manager.

Generated at Mon Feb 12 03:19:24 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.