[#XWIKI-2359] Move xwiki cache service as new XWiki Plexus component

XWiki Core

Move xwiki cache service as new XWiki Plexus component

Created: 02/May/08 11:24 Updated: 24/Jun/08 10:12

Component/s:

Build, Infrastructure and Tests, Cache, Core

Affects Version/s:

None

Fix Version/s:

1.5 M2

File Attachments:

cache.zip (61 kB)
2.

cache.zip (62 kB)
3.

cache.zip (66 kB)
4.

cache.zip (53 kB)
5.

cache.zip (47 kB)
6.

cache.zip (48 kB)
7.

cache.zip (54 kB)
8.

cache.zip (55 kB)

Issue Links:

Dependency

This issue blocks:

XWIKI-2400 Create a cache component implementation based on memcached

~~XWIKI-2399~~ Create a cache component implementation based on JBoss

This issue depends on:

~~XWIKI-2469~~ Create a cache component implementation based on OSCache

~~XWIKI-2367~~ Makes ComponentManager gettable without the XWikiContext

Related

This issue relates to:

XWIKI-2452 Fix OSCache Clustering

Resolution Date:	24/Jun/08 10:12
Tests:	Integration, Unit

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 02/May/08 17:19

I have some issues with code directly using OSCache in place of using general cache service interface :

XWikiCacheListener initialized in XWiki.initXWiki method
in internal image plugin, a cache is created with OSCache specifics properties (ImagePlugin.initCache method). Is all this really needed ?

If someone has some ideas...

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 06/May/08 11:17

Even its initialised by XWiki, XWikiCacheListener seems not used anywhere...

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 13/May/08 15:07

Here is a first way to do it with a oscache implementation

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 20/May/08 16:42

I don't really understand why we need to reimplement JavaGroupsBroadcastingListener another way in SharedJavaGroupsBroadcastingListener.java. There is a comment but it does not says why the opensymphony implementation is not good for us...

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 21/May/08 15:15

introduce cache events
add jboss local cache implementation (not complete/tested yet)
refactor api names in a more generic way

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 26/May/08 11:53

introduce generics in cache api

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 27/May/08 16:55

I think I have an idea of how fix most all my cache configuration problems. Provide a configuration id used to access the real configuration by the implementation. For example image plugin privide an id "xwiki.pligin.image" and the OSCache cache component get the configuration in "WEB-INF/oscache/xwiki.plugin.image.properties" file or "WEB-INF/oscache/default.properties" if it can't find anything. This permit to have complex configuration if needed without having tons of properties in the api for which to find translations in all different implementations.

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 27/May/08 17:12

Even this means having a config file for each cache implementation we don't have so many very specific cache optimisation, in fact currently we only have image plugin and this way it's easier to modify configuration for an admin.

For eviction policy even if it's technically possible to do that way It can generate too many configurations and we need a more dynamic support in the api...

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 27/May/08 17:14

Anyway this is useful for an admin to overwrite cache configuration in code to better feat his use case.

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 27/May/08 19:43

introduce cache configuration id
add web-standard patch containing new default cache configuration for oscache and jbosscache and plugin image oscache config file

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 28/May/08 17:16

improve CacheConfiguration oscache implementation

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 05/Jun/08 16:53

introduce eviction configuration (only contains "NONE" and "LRU" for now)

OSCache does not provide any real eviction policy system api. We could extends OSCache abstract cache and implement in it a JBoss Cache like eviction policy. It is not very difficult but for now I prefer to use the provided API. An eviction policy will be easy to add latter. For now LRU eviction configuration cover most of our use cases :

limited capacity (which can be infinite)
time to live (which can be infinite)

cache name is now configuration id located in CacheConfiguration

to get a new cache the user has to provide a CacheConfiguration.

This makes LocalCacheFactory and CacheFactory pretty much the same.
When I find a clean way to be able to separate "local" and "normal" caches in different possibles implementations I will remove the factories and makes cache components

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 06/Jun/08 16:02 - edited

improve OSCache and JBossCache cach initialization. I would like to completely remove factories but I can't find a ways to support JAVA 1.5 generics in a plexus component role.
introduce VersionnableCacheValue interface indicating that a cached value contains a marker used in a distributed cache where the real data is stored in the local cache. This to speed up the distributed cache process.

[ Permlink | « Hide ]

Thomas Mortagne added a comment - 06/Jun/08 16:38 - edited

remove the LocalCacheFactory role (as it's now exactly the same api than CacheFactory) and differentiate normal/local by Plexus role-hint