27 May
2008
27 May
'08
10:35 a.m.
Hi Thomas,
I know you're working on the new cache component (btw would be nice if
you could send an email with your planned architecture/api so that it
can be reviewed - like show the APIs) so I thought I should give you
some needs/ideas I have on this topic.
* We need several types of local caches. I can see at least the
following types:
- a timed cache. I need this for example to cache macros
- a cache with a fixed given capacity and expiring the oldest entries
(not really sure where we need this right now but it looks common
enough)
- a cache with a fixed given capacity and expiring the least accessed
entries (not really sure where we need this right now but it looks
common enough)
- a cache with unlimited capacity and bound only by the memory
available. The way to implement this is using PhantomReference.
Basically it's the JVM that calls back the reference to tell it it
needs memory. I was told that the new google collections api have some
code that do this (I think FinalizablePhantomReference). This cache is
the one I would use to save wiki pages' AST in memory.
Of course we shouldn't implement anything ourselves and we should use
existing framework(s) underneath our own API for the Cache API.
WDYT?
Links:
* http://www.realjenius.com/node/377
*
http://www.javalobby.org/forums/thread.jspa?threadID=16520&messageID=91…
Thanks
-Vincent
27 May
27 May
10:43 a.m.
Some more thoughts:
1) Actually we can probably use the google collections api for all our
needs. For example it has
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/commo…
2) I'm not sure the PhantomReference is correct. It would be useful if
we wanted to save the AST on disk for example but I don't know if that
would win us processing time or not. It may. Otherwise a SoftReference
would be enough. The difference is that with PhantomeReference the JVM
calls you before the item is reclaimed so you can do something with it
before it's too late...
3) If we want to go in this direction we'll need to decide if we want
to continue using only the Apache Collections fwk or if it's ok to use
both google's and apache's.
4) Do you know of any existing cache framework that we could use
directly? (I haven't researched this but you probably have).
Thanks
-Vincent
On May 27, 2008, at 10:35 AM, Vincent Massol wrote:
Hi Thomas,
I know you're working on the new cache component (btw would be nice if
you could send an email with your planned architecture/api so that it
can be reviewed - like show the APIs) so I thought I should give you
some needs/ideas I have on this topic.
* We need several types of local caches. I can see at least the
following types:
- a timed cache. I need this for example to cache macros
- a cache with a fixed given capacity and expiring the oldest entries
(not really sure where we need this right now but it looks common
enough)
- a cache with a fixed given capacity and expiring the least accessed
entries (not really sure where we need this right now but it looks
common enough)
- a cache with unlimited capacity and bound only by the memory
available. The way to implement this is using PhantomReference.
Basically it's the JVM that calls back the reference to tell it it
needs memory. I was told that the new google collections api have some
code that do this (I think FinalizablePhantomReference). This cache is
the one I would use to save wiki pages' AST in memory.
Of course we shouldn't implement anything ourselves and we should use
existing framework(s) underneath our own API for the Cache API.
WDYT?
Links:
* http://www.realjenius.com/node/377
*
http://www.javalobby.org/forums/thread.jspa?threadID=16520&messageID=91…
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:24 p.m.
Hi Vincent,
I already sent a mail (http://markmail.org/message/euavqzjz53mxxkut)
explaining the cache service -> cache components I planned/coded. You
can find a first api and a complete oscache implementation at
http://jira.xwiki.org/jira/browse/XWIKI-2359.
I designed this api looking to all places we used the old cache
service and all this used to support. Lets list here the main lines of
it :
1) What the new api already contains (see
http://jira.xwiki.org/jira/browse/XWIKI-2359) :
1.1) First of all, there is two different component roles :
* cache : create named cache that can be local or distributed
caches depends on the implementation and its configuration. Typically
used for documents cache.
* local cache : create only and always local caches seems to be
needed by some part of XWiki core like groovy, feed plugin and image
plugin
That way we can set in the configuration that we want memcached for
normal cache and JBossCache for local cache for example.
1.2) Factory create cache and take parameters like "capacity"
1.3) Cache contains :
* get : get the value by key, can take a timing as parameter
compared to the time the value was registered the last time
* set : modify or add a value to the cache
* remove : remove a value from the cache
1.4) Cache can call listeners on add, delete, update...
1.5) Cache support generics
This api support all you listed I think (except for the way the timed
cache works). It is generally based on the old cache services concepts
even all the names changes but the more I'm working with JBoss cache
the more I think this api need some changes as JBoss cache and OSCache
has very different way to create there caches.
2) Problems/not sure yet :
2.1) old cache service provide methods taking maps of properties as
parameters need by image plugin for example. My problem here is that
all existing cache frameworks like OSCache, JBoss etc... are very new
to me and I'm not sure of what feature I can generalize in this map. I
think of starting by taking all properties setted by image plugin and
list them as XWiki Cache properties and translate them for each
implementations. Capacity, name all Factory take as parameters should
be included in a CacheConfiguration object. Some of theses properties
can also be ignored by implementation in some cases.
2.2) I think I need to change the way the timing works in this api
as I did not find how to support it in JBoss yet. A more restrictive
way and supported by JBoss would be to provided the limit time for the
whole cache. I don"t really see a need for more. I'm thinking of
introduce eviction algorithms concept like JBoss or cache4j do to
replace the way restriction like capacity and timing are supported.
3) Other features the cache component could support for XWiki needs
3.1) for documents cache, Ludovic proposed the idea of something
like a "meta cache" when we are using distributed cache: the idea is
to only store the documents version in the distributed cache and store
the reall document in a local cache. The local cache is synchronised
with distributed cache based on the documents version:if it changed
the document has to be reloaded from the database. This avoid the
serialization/unserialization process of the whole document in the
distributed cache.
On Tue, May 27, 2008 at 10:43 AM, Vincent Massol <vincent(a)massol.net> wrote:
Some more thoughts:
1) Actually we can probably use the google collections api for all our
needs. For example it has
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/commo…
2) I'm not sure the PhantomReference is correct. It would be useful if
we wanted to save the AST on disk for example but I don't know if that
would win us processing time or not. It may. Otherwise a SoftReference
would be enough. The difference is that with PhantomeReference the JVM
calls you before the item is reclaimed so you can do something with it
before it's too late...
3) If we want to go in this direction we'll need to decide if we want
to continue using only the Apache Collections fwk or if it's ok to use
both google's and apache's.
4) Do you know of any existing cache framework that we could use
directly? (I haven't researched this but you probably have).
Plexus cache api
(http://plexus.codehaus.org/plexus-components/plexus-cache/plexus-cache-api/…)
and some implementations. The problem is that the api is not very
generic and the way it is designed you need to know the implementation
you use to correctly configure the cache to create. But maybe I take
it the wrong way and should not try to force the whole XWiki Platform
to be able to use any cache component implementation...
Except for the plexus one I did not found a real "framework of cache
framework" but I did not search weeks for it...
Thanks
-Vincent
On May 27, 2008, at 10:35 AM, Vincent Massol wrote:
--
Thomas Mortagne
Hi Thomas,
I know you're working on the new cache component (btw would be nice if
you could send an email with your planned architecture/api so that it
can be reviewed - like show the APIs) so I thought I should give you
some needs/ideas I have on this topic.
* We need several types of local caches. I can see at least the
following types:
- a timed cache. I need this for example to cache macros
- a cache with a fixed given capacity and expiring the oldest entries
(not really sure where we need this right now but it looks common
enough)
- a cache with a fixed given capacity and expiring the least accessed
entries (not really sure where we need this right now but it looks
common enough)
- a cache with unlimited capacity and bound only by the memory
available. The way to implement this is using PhantomReference.
Basically it's the JVM that calls back the reference to tell it it
needs memory. I was told that the new google collections api have some
code that do this (I think FinalizablePhantomReference). This cache is
the one I would use to save wiki pages' AST in memory.
Of course we shouldn't implement anything ourselves and we should use
existing framework(s) underneath our own API for the Cache API.
WDYT?
Links:
* http://www.realjenius.com/node/377
*
http://www.javalobby.org/forums/thread.jspa?threadID=16520&messageID=91…
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:45 p.m.
I just created a page on design space:
http://dev.xwiki.org/xwiki/bin/view/Design/XWikiCacheComponent
On Tue, May 27, 2008 at 12:24 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
Hi Vincent,
I already sent a mail (http://markmail.org/message/euavqzjz53mxxkut)
explaining the cache service -> cache components I planned/coded. You
can find a first api and a complete oscache implementation at
http://jira.xwiki.org/jira/browse/XWIKI-2359.
I designed this api looking to all places we used the old cache
service and all this used to support. Lets list here the main lines of
it :
1) What the new api already contains (see
http://jira.xwiki.org/jira/browse/XWIKI-2359) :
1.1) First of all, there is two different component roles :
* cache : create named cache that can be local or distributed
caches depends on the implementation and its configuration. Typically
used for documents cache.
* local cache : create only and always local caches seems to be
needed by some part of XWiki core like groovy, feed plugin and image
plugin
That way we can set in the configuration that we want memcached for
normal cache and JBossCache for local cache for example.
1.2) Factory create cache and take parameters like "capacity"
1.3) Cache contains :
* get : get the value by key, can take a timing as parameter
compared to the time the value was registered the last time
* set : modify or add a value to the cache
* remove : remove a value from the cache
1.4) Cache can call listeners on add, delete, update...
1.5) Cache support generics
This api support all you listed I think (except for the way the timed
cache works). It is generally based on the old cache services concepts
even all the names changes but the more I'm working with JBoss cache
the more I think this api need some changes as JBoss cache and OSCache
has very different way to create there caches.
2) Problems/not sure yet :
2.1) old cache service provide methods taking maps of properties as
parameters need by image plugin for example. My problem here is that
all existing cache frameworks like OSCache, JBoss etc... are very new
to me and I'm not sure of what feature I can generalize in this map. I
think of starting by taking all properties setted by image plugin and
list them as XWiki Cache properties and translate them for each
implementations. Capacity, name all Factory take as parameters should
be included in a CacheConfiguration object. Some of theses properties
can also be ignored by implementation in some cases.
2.2) I think I need to change the way the timing works in this api
as I did not find how to support it in JBoss yet. A more restrictive
way and supported by JBoss would be to provided the limit time for the
whole cache. I don"t really see a need for more. I'm thinking of
introduce eviction algorithms concept like JBoss or cache4j do to
replace the way restriction like capacity and timing are supported.
3) Other features the cache component could support for XWiki needs
3.1) for documents cache, Ludovic proposed the idea of something
like a "meta cache" when we are using distributed cache: the idea is
to only store the documents version in the distributed cache and store
the reall document in a local cache. The local cache is synchronised
with distributed cache based on the documents version:if it changed
the document has to be reloaded from the database. This avoid the
serialization/unserialization process of the whole document in the
distributed cache.
On Tue, May 27, 2008 at 10:43 AM, Vincent Massol <vincent(a)massol.net> wrote:
--
Thomas Mortagne
Some more thoughts:
1) Actually we can probably use the google collections api for all our
needs. For example it has
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/commo…
2) I'm not sure the PhantomReference is correct. It would be useful if
we wanted to save the AST on disk for example but I don't know if that
would win us processing time or not. It may. Otherwise a SoftReference
would be enough. The difference is that with PhantomeReference the JVM
calls you before the item is reclaimed so you can do something with it
before it's too late...
3) If we want to go in this direction we'll need to decide if we want
to continue using only the Apache Collections fwk or if it's ok to use
both google's and apache's.
4) Do you know of any existing cache framework that we could use
directly? (I haven't researched this but you probably have).
Plexus cache api
(http://plexus.codehaus.org/plexus-components/plexus-cache/plexus-cache-api/…)
and some implementations. The problem is that the api is not very
generic and the way it is designed you need to know the implementation
you use to correctly configure the cache to create. But maybe I take
it the wrong way and should not try to force the whole XWiki Platform
to be able to use any cache component implementation...
Except for the plexus one I did not found a real "framework of cache
framework" but I did not search weeks for it...
Thanks
-Vincent
On May 27, 2008, at 10:35 AM, Vincent Massol wrote:
--
Thomas Mortagne
Hi Thomas,
I know you're working on the new cache component (btw would be nice if
you could send an email with your planned architecture/api so that it
can be reviewed - like show the APIs) so I thought I should give you
some needs/ideas I have on this topic.
* We need several types of local caches. I can see at least the
following types:
- a timed cache. I need this for example to cache macros
- a cache with a fixed given capacity and expiring the oldest entries
(not really sure where we need this right now but it looks common
enough)
- a cache with a fixed given capacity and expiring the least accessed
entries (not really sure where we need this right now but it looks
common enough)
- a cache with unlimited capacity and bound only by the memory
available. The way to implement this is using PhantomReference.
Basically it's the JVM that calls back the reference to tell it it
needs memory. I was told that the new google collections api have some
code that do this (I think FinalizablePhantomReference). This cache is
the one I would use to save wiki pages' AST in memory.
Of course we shouldn't implement anything ourselves and we should use
existing framework(s) underneath our own API for the Cache API.
WDYT?
Links:
* http://www.realjenius.com/node/377
*
http://www.javalobby.org/forums/thread.jspa?threadID=16520&messageID=91…
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:34 p.m.
Hi Thomas,
On May 27, 2008, at 12:24 PM, Thomas Mortagne wrote:
Hi Vincent,
I already sent a mail (http://markmail.org/message/euavqzjz53mxxkut)
explaining the cache service -> cache components I planned/coded.
Yes sorry I forgot about that mail :)
You
can find a first api and a complete oscache implementation at
http://jira.xwiki.org/jira/browse/XWIKI-2359.
Haven't found the time to look at the patch yet. I thought it might be
easy if you explain it, which you did below.
I designed this api looking to all places we used the
old cache
service and all this used to support. Lets list here the main lines of
it :
1) What the new api already contains (see
http://jira.xwiki.org/jira/browse/XWIKI-2359) :
1.1) First of all, there is two different component roles :
* cache : create named cache that can be local or distributed
caches depends on the implementation and its configuration. Typically
used for documents cache.
* local cache : create only and always local caches seems to be
needed by some part of XWiki core like groovy, feed plugin and image
plugin
Could you explain why we need 2 cache roles?. Why not a single Cache
role but with different role hints?
Examples of hints:
* "local/LRU"
* "distributed/oscache"
* "memcached"
* "jbosscache/local"
etc.
or simply:
"local"
"distributed"
I'm not saying it's bad but it looks strange to have a method to
create local and distributed caches and another one to create local
caches only. It's not balanced and I think that reflects a problem in
the API.
Cannot we consider the fact that the cache is distributed or not a
configuration of the cache? That's unless the 2 cache interfaces are
different.
That way we can set in the configuration that we want
memcached for
normal cache and JBossCache for local cache for example.
1.2) Factory create cache and take parameters like "capacity"
I think it should maybe also take an EvictionPolicy. The capacity
could be a parameter of the EvictionPolicy. Some caches don't require
a "capacity" so I don't think the capacity should be in the method for
creating a cache.
1.3) Cache contains :
* get : get the value by key, can take a timing as parameter
compared to the time the value was registered the last time
Hmm... Not sure I like this timing too much. How do the oscache and
jbosscache do this?
* set : modify or add a value to the cache
* remove : remove a value from the cache
How do you configure a cache?
1.4) Cache can call listeners on add, delete,
update...
By listeners do you mean the Observation component?
We definitely need to support the use case where a cache of documents
removes a given document when it's modified. I'd say that this should
be implemented using an EvictionPolicy implementation.
1.5) Cache support generics
This api support all you listed I think (except for the way the timed
cache works). It is generally based on the old cache services concepts
even all the names changes but the more I'm working with JBoss cache
the more I think this api need some changes as JBoss cache and OSCache
has very different way to create there caches.
We should definitely not base our new API on the existing xwiki API.
Instead we should focus on the general needs we have and on the state
of the art about caching.
2) Problems/not sure yet :
2.1) old cache service provide methods taking maps of properties as
parameters need by image plugin for example.
Not sure I understand this.
My problem here is that
all existing cache frameworks like OSCache, JBoss etc... are very new
to me and I'm not sure of what feature I can generalize in this map. I
think of starting by taking all properties setted by image plugin and
list them as XWiki Cache properties and translate them for each
implementations. Capacity, name all Factory take as parameters should
be included in a CacheConfiguration object. Some of theses properties
can also be ignored by implementation in some cases.
2.2) I think I need to change the way the timing works in this api
as I did not find how to support it in JBoss yet. A more restrictive
way and supported by JBoss would be to provided the limit time for the
whole cache. I don"t really see a need for more. I'm thinking of
introduce eviction algorithms concept like JBoss or cache4j do to
replace the way restriction like capacity and timing are supported.
Yep, see above.
3) Other features the cache component could support
for XWiki needs
3.1) for documents cache, Ludovic proposed the idea of something
like a "meta cache" when we are using distributed cache: the idea is
to only store the documents version in the distributed cache and store
the reall document in a local cache. The local cache is synchronised
with distributed cache based on the documents version:if it changed
the document has to be reloaded from the database. This avoid the
serialization/unserialization process of the whole document in the
distributed cache.
No comment on this yet. Haven't thought about it deeply enough...
On Tue, May 27, 2008 at 10:43 AM, Vincent Massol
<vincent(a)massol.net> wrote:
> Some more thoughts:
>
> 1) Actually we can probably use the google collections api for all
> our
> needs. For example it has
>
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/commo…
>
> 2) I'm not sure the PhantomReference is correct. It would be useful
> if
> we wanted to save the AST on disk for example but I don't know if
> that
> would win us processing time or not. It may. Otherwise a
> SoftReference
> would be enough. The difference is that with PhantomeReference the
> JVM
> calls you before the item is reclaimed so you can do something with
> it
> before it's too late...
>
> 3) If we want to go in this direction we'll need to decide if we want
> to continue using only the Apache Collections fwk or if it's ok to
> use
> both google's and apache's.
>
> 4) Do you know of any existing cache framework that we could use
> directly? (I haven't researched this but you probably have).
After more thought I don't think we need all of this and we should use
directly one of the cache frameworks and not redo it. So we should use
directly jbosscache or oscache. The different strategies should
probably be implemented as EvictionPolicy.
Plexus cache api
(http://plexus.codehaus.org/plexus-components/plexus-cache/plexus-cache-api/…
)
and some implementations. The problem is that the api is not very
generic and the way it is designed you need to know the implementation
you use to correctly configure the cache to create. But maybe I take
it the wrong way and should not try to force the whole XWiki Platform
to be able to use any cache component implementation...
Except for the plexus one I did not found a real "framework of cache
framework" but I did not search weeks for it...
We shouldn't use Plexus IMO. We need our own Caching API. It's only
the implementation that we shouldn't do and instead wrap jbosscache,
oscache, etc. In addition the plexus cache is not something mature
enough compared to jbosscache, oscache, etc.
Thanks
-Vincent
> On May 27, 2008, at 10:35 AM, Vincent Massol
wrote:
>
>> Hi Thomas,
>>
>> I know you're working on the new cache component (btw would be
>> nice if
>> you could send an email with your planned architecture/api so that
>> it
>> can be reviewed - like show the APIs) so I thought I should give you
>> some needs/ideas I have on this topic.
>>
>> * We need several types of local caches. I can see at least the
>> following types:
>> - a timed cache. I need this for example to cache macros
>> - a cache with a fixed given capacity and expiring the oldest
>> entries
>> (not really sure where we need this right now but it looks common
>> enough)
>> - a cache with a fixed given capacity and expiring the least
>> accessed
>> entries (not really sure where we need this right now but it looks
>> common enough)
>> - a cache with unlimited capacity and bound only by the memory
>> available. The way to implement this is using PhantomReference.
>> Basically it's the JVM that calls back the reference to tell it it
>> needs memory. I was told that the new google collections api have
>> some
>> code that do this (I think FinalizablePhantomReference). This
>> cache is
>> the one I would use to save wiki pages' AST in memory.
>>
>> Of course we shouldn't implement anything ourselves and we should
>> use
>> existing framework(s) underneath our own API for the Cache API.
>>
>> WDYT?
>>
>> Links:
>> * http://www.realjenius.com/node/377
>> *
http://www.javalobby.org/forums/thread.jspa?threadID=16520&messageID=91…
>>
>> Thanks
>> -Vincent
3:48 p.m.
On Tue, May 27, 2008 at 2:34 PM, Vincent Massol <vincent(a)massol.net> wrote:
Yes me too I just did not rewritten this from the old api (based on
OSCache) but as I said something based on eviction algorithms/policy
like JBoss do this would be better.
After seeing all the difference there at least between OSCache and
JBossCache I did not take the risk of adding dynamic configuration
modification and consider configuration at creation time would be
enough.
No just that Cache api provide "classical" java listeners in the cache
objects. I don't see the need for the whole platform to get event on a
cache except for the code knowing and using this cache. For example
CacheStore catch it's cache object events and can dispatch related
documents events using Observation component.
Look at image plugin (which is the only one using it) code at
http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-core/src….
The cache factory takes a Properties object containing OSCache
specific configuration like "cache.memory", "cache.unlimited.disk",
"cache.persistence.class", etc.
I don't know if all this specific configuration is really needed here
as I don't know very well the image plugin.
This would be definitely easier and come with a cleaner API that we
could ever design (especially JBossCache IMO). Given the fact that
there is no XWiki specifics needs in the old or the new XWiki cache
service/component, the more I think of it the more making our generic
and clean cache framework seems too expensive for a project like
XWiki...
But it means we can't do what the framwork we use can't do. I don't
say I really see anything we need which is not supported by any of
these but if we want to change to one we use by another it could be a
pain. If memcached is way better than JBossCache distributed cache
implementations can we use it through JBossCache (I think it's
possible) ? etc.
All this refactor was launched by our desire to change OSCache by JBossCache...
--
Thomas Mortagne
Hi Thomas,
On May 27, 2008, at 12:24 PM, Thomas Mortagne wrote:
Maybe if it was local or distributed cache but here we have some code
specifically asking for local cache and the others don't care. XWiki
will not always run with a configured distributed cache behind it so
for me a code in the platform can't ask for more than a cache which
will be distributed or not depends of the implementation and its
configuration. I don't see local/normal at the same level as
implementation so I made two different roles. Maybe I see
"implementation" too restrictively...
Hi Vincent,
I already sent a mail (http://markmail.org/message/euavqzjz53mxxkut)
explaining the cache service -> cache components I planned/coded.
Yes sorry I forgot about that mail :)
You
can find a first api and a complete oscache implementation at
http://jira.xwiki.org/jira/browse/XWIKI-2359.
Haven't found the time to look at the patch yet. I thought it might be
easy if you explain it, which you did below.
I designed this api looking to all places we used
the old cache
service and all this used to support. Lets list here the main lines of
it :
1) What the new api already contains (see
http://jira.xwiki.org/jira/browse/XWIKI-2359) :
1.1) First of all, there is two different component roles :
* cache : create named cache that can be local or distributed
caches depends on the implementation and its configuration. Typically
used for documents cache.
* local cache : create only and always local caches seems to be
needed by some part of XWiki core like groovy, feed plugin and image
plugin
Could you explain why we need 2 cache roles?. Why not a single Cache
role but with different role hints?
Examples of hints:
* "local/LRU"
* "distributed/oscache"
* "memcached"
* "jbosscache/local"
etc.
or simply:
"local"
"distributed"
I'm not saying it's bad but it looks strange to have a method to
create local and distributed caches and another one to create local
caches only. It's not balanced and I think that reflects a problem in
the API.
Cannot we consider the fact that the cache is distributed or not a
configuration of the cache? That's unless the 2 cache interfaces are
different.
There is only one real differences (yet) in the two interfaces: a
local cache does not need to be named
That way we can set in the configuration that we
want memcached for
normal cache and JBossCache for local cache for example.
1.2) Factory create cache and take parameters like "capacity"
I think it should maybe also take an EvictionPolicy. The capacity
could be a parameter of the EvictionPolicy. Some caches don't require
a "capacity" so I don't think the capacity should be in the method for
creating a cache.
1.3) Cache contains :
* get : get the value by key, can take a timing as parameter
compared to the time the value was registered the last time
Hmm... Not sure I like this timing too much. How do the oscache and
jbosscache do this? * set : modify or add a value to the cache
* remove : remove a value from the cache
How do you configure a cache? 1.4) Cache can call listeners on add, delete,
update...
By listeners do you mean the Observation component?
We definitely need to support the use case where a cache of documents
removes a given document when it's modified. I'd say that this should
be implemented using an EvictionPolicy implementation.
The existing API is no much more than an OSCache wrapper with same
names and same concepts so it's not totally pure XWiki quick thinking.
1.5) Cache support generics
This api support all you listed I think (except for the way the timed
cache works). It is generally based on the old cache services concepts
even all the names changes but the more I'm working with JBoss cache
the more I think this api need some changes as JBoss cache and OSCache
has very different way to create there caches.
We should definitely not base our new API on the existing xwiki API.
Instead we should focus on the general needs we have and on the state
of the art about caching. 2) Problems/not sure yet :
2.1) old cache service provide methods taking maps of properties as
parameters need by image plugin for example.
Not sure I understand this. My problem here is that
all existing cache frameworks like OSCache, JBoss etc... are very new
to me and I'm not sure of what feature I can generalize in this map. I
think of starting by taking all properties setted by image plugin and
list them as XWiki Cache properties and translate them for each
implementations. Capacity, name all Factory take as parameters should
be included in a CacheConfiguration object. Some of theses properties
can also be ignored by implementation in some cases.
2.2) I think I need to change the way the timing works in this api
as I did not find how to support it in JBoss yet. A more restrictive
way and supported by JBoss would be to provided the limit time for the
whole cache. I don"t really see a need for more. I'm thinking of
introduce eviction algorithms concept like JBoss or cache4j do to
replace the way restriction like capacity and timing are supported.
Yep, see above.
3) Other features the cache component could
support for XWiki needs
3.1) for documents cache, Ludovic proposed the idea of something
like a "meta cache" when we are using distributed cache: the idea is
to only store the documents version in the distributed cache and store
the reall document in a local cache. The local cache is synchronised
with distributed cache based on the documents version:if it changed
the document has to be reloaded from the database. This avoid the
serialization/unserialization process of the whole document in the
distributed cache.
No comment on this yet. Haven't thought about it deeply enough...
On Tue, May 27, 2008 at 10:43 AM, Vincent Massol
<vincent(a)massol.net> wrote:
> Some more thoughts:
>
> 1) Actually we can probably use the google collections api for all
> our
> needs. For example it has
>
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/commo…
>
> 2) I'm not sure the PhantomReference is correct. It would be useful
> if
> we wanted to save the AST on disk for example but I don't know if
> that
> would win us processing time or not. It may. Otherwise a
> SoftReference
> would be enough. The difference is that with PhantomeReference the
> JVM
> calls you before the item is reclaimed so you can do something with
> it
> before it's too late...
>
> 3) If we want to go in this direction we'll need to decide if we want
> to continue using only the Apache Collections fwk or if it's ok to
> use
> both google's and apache's.
>
> 4) Do you know of any existing cache framework that we could use
> directly? (I haven't researched this but you probably have).
After more thought I don't think we need all of this and we should use
directly one of the cache frameworks and not redo it. So we should use
directly jbosscache or oscache. The different strategies should
probably be implemented as EvictionPolicy. Plexus cache api
(http://plexus.codehaus.org/plexus-components/plexus-cache/plexus-cache-api/…
)
and some implementations. The problem is that the api is not very
generic and the way it is designed you need to know the implementation
you use to correctly configure the cache to create. But maybe I take
it the wrong way and should not try to force the whole XWiki Platform
to be able to use any cache component implementation...
Except for the plexus one I did not found a real "framework of cache
framework" but I did not search weeks for it...
We shouldn't use Plexus IMO. We need our own Caching API. It's only
the implementation that we shouldn't do and instead wrap jbosscache,
oscache, etc. In addition the plexus cache is not something mature
enough compared to jbosscache, oscache, etc.
Thanks
-Vincent
> On May 27, 2008, at 10:35 AM, Vincent Massol
wrote:
>
>> Hi Thomas,
>>
>> I know you're working on the new cache component (btw would be
>> nice if
>> you could send an email with your planned architecture/api so that
>> it
>> can be reviewed - like show the APIs) so I thought I should give you
>> some needs/ideas I have on this topic.
>>
>> * We need several types of local caches. I can see at least the
>> following types:
>> - a timed cache. I need this for example to cache macros
>> - a cache with a fixed given capacity and expiring the oldest
>> entries
>> (not really sure where we need this right now but it looks common
>> enough)
>> - a cache with a fixed given capacity and expiring the least
>> accessed
>> entries (not really sure where we need this right now but it looks
>> common enough)
>> - a cache with unlimited capacity and bound only by the memory
>> available. The way to implement this is using PhantomReference.
>> Basically it's the JVM that calls back the reference to tell it it
>> needs memory. I was told that the new google collections api have
>> some
>> code that do this (I think FinalizablePhantomReference). This
>> cache is
>> the one I would use to save wiki pages' AST in memory.
>>
>> Of course we shouldn't implement anything ourselves and we should
>> use
>> existing framework(s) underneath our own API for the Cache API.
>>
>> WDYT?
>>
>> Links:
>> * http://www.realjenius.com/node/377
>> *
http://www.javalobby.org/forums/thread.jspa?threadID=16520&messageID=91…
>>
>> Thanks
>> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:20 a.m.
Hello XWiki devs,
I may be diverging since this is not so much about the back-end
caching infrastructure, but I would like to insist on one practice for
caching which such a cache architecture should support: the most
common use of a cache that we have been experimenting with is not that
clients simply do not call again because it's in cache (this happens
but not in most cases), they call with an added header If-Modified-
Since, which contains a date. That date is the date the client last
cached the given resource.
The interest is when the server responds the status code 304 (Not
Modified) which basically says "your cache is good".
Think of something such as a javascript, CSS, or HTML file, cached in
a browser,... this means no reparsing needed, a very useful statement
to save CPU and memory (as well as bandwidth, but that is less a
problem)!
Note also that such a call is very tiny, 10 lines of headers up-
stream, three-lines downstream, very little if the connection is kept-
alive. And it does provide up-to-date-ness guarantees whereas the
practice of not checking if a cached resource is up-to-date (because
the cache is "fresh enough") fails at providing this guarantee.
A way to implement this approach on the back-end would be to have some
of the retrieval calls to contain such a parameter as "if-modified-
since" and have an exception be thrown if it is not modified.
I believe that even some of the tags with a page that I heard about in
Vincent's talk are candidate to support such an infrastructure, being
able, if mature, to look into their sources if there's anything
changed since that date.
As I understand, this is not what tomcat does on the default file-
serving servlets and this is the reason we keep seeing these spurious
loads (e.g. picture curtain of load). Don't ask me why Tomcat chose
not to make it such.
paul
Le 27-mai-08 à 10:35, Vincent Massol a écrit :
Hi Thomas,
I know you're working on the new cache component (btw would be nice if
you could send an email with your planned architecture/api so that it
can be reviewed - like show the APIs) so I thought I should give you
some needs/ideas I have on this topic.
* We need several types of local caches. I can see at least the
following types:
- a timed cache. I need this for example to cache macros
- a cache with a fixed given capacity and expiring the oldest entries
(not really sure where we need this right now but it looks common
enough)
- a cache with a fixed given capacity and expiring the least accessed
entries (not really sure where we need this right now but it looks
common enough)
- a cache with unlimited capacity and bound only by the memory
available. The way to implement this is using PhantomReference.
Basically it's the JVM that calls back the reference to tell it it
needs memory. I was told that the new google collections api have some
code that do this (I think FinalizablePhantomReference). This cache is
the one I would use to save wiki pages' AST in memory.
Of course we shouldn't implement anything ourselves and we should use
existing framework(s) underneath our own API for the Cache API.
WDYT?
Links:
* http://www.realjenius.com/node/377
*
http://www.javalobby.org/forums/thread.jspa?threadID=16520&messageID=91…
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6366
days inactive
6366
days old
6 comments
3 participants
participants (3)
-
Paul Libbrecht -
Thomas Mortagne -
Vincent Massol