[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: |
|
| 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- |
| Comment by Sameer Charles [ 13/Feb/06 ] |
|
Great! 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 |
| 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.
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. |
| Comment by Fabrizio Giustina [ 11/Mar/06 ] |
|
done:
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. |
| 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. other todos:
Give it look and report your impressions, please |
| Comment by Magnolia International [ 10/Oct/07 ] |
|
status, feedback, comments ? |
| 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. |