You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Unico Hommes <un...@hippo.nl> on 2004/09/28 16:20:00 UTC
Fw: [SourceForge.net Release] ehcache : ehcache
SourceForge.net wrote:
>Project: ehcache (ehcache)
>Package: ehcache
>Date : 2004-09-28 07:03
>
>Project "ehcache" ('ehcache') has released the new version of package 'ehcache'.
>You can download it from SourceForge.net by following this link:
><https://sourceforge.net/project/showfiles.php?group_id=93232&release_id=271146>
>or browse Release Notes and ChangeLog by visiting this link:
><https://sourceforge.net/project/shownotes.php?release_id=271146>
>
>
I believe this was to be our cue for moving ehcache based store to the
core and making it our default right? I have just updated our ehcache to
the new release version but haven't yet moved it to the core. If noone
objects I will move it to the core later.
There still remains one FIXME in the EHCache store implementation
though. Method free() hasn't been implemented. AFAIK this one is called
by the StoreJanitor to do its work. However, although it works a little
different from ours, EHCache has its own kind of janitor mechanism that
operates on the basis of time-to-live and time-to-idle expiry
strategies. Will this be sufficient or should we try to come up with
some sort of implementation of the free() method?
Another thing to keep in mind is that EHCacheStore cannot be used in the
role of a transient store. This is because it requires entries to be
Serializable even if it is configured not to be persistence enabled. I
will file an enhancement request to the ehcache guys like we did with
JCS at the time, to remove this requirement.
--
Unico
Re: Fw: [SourceForge.net Release] ehcache : ehcache
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Unico Hommes wrote:
> Vadim Gritsenko wrote:
>
>> Unico Hommes wrote:
>>
>>> There still remains one FIXME in the EHCache store implementation
>>> though. Method free() hasn't been implemented. AFAIK this one is
>>> called by the StoreJanitor to do its work. However, although it works
>>> a little different from ours, EHCache has its own kind of janitor
>>> mechanism that operates on the basis of time-to-live and time-to-idle
>>> expiry strategies. Will this be sufficient or should we try to come
>>> up with some sort of implementation of the free() method?
>>
>>
>> No, it won't be sufficient. Janitor checks that JVM is not starving,
>> and cache *must* react on low-memory condition regardless of
>> time-to-live and other bells-and-wistles.
>
>
> Then what about implementing free() so that it removes a specified
> number of elements? Perhaps there is a possibility to find out the LRU
> ones. I believe StoreJanitor tries to free memory until the low-memory
> condition goes away, so such an implementation would suffice right?
free() should free up just one element from the cache. Ideally, it
should be LRU or just-to-be-expired (it should keep list of expiration
times, right?) cache element. Janitor will take care about freeing up as
much elements as necessary (from all registered caches).
See [1] for reference free() implementation ;-)
Vadim
[1]
http://svn.apache.org/repos/asf/excalibur/trunk/components/store/src/java/org/apache/excalibur/store/impl/MRUMemoryStore.java
Re: Fw: [SourceForge.net Release] ehcache : ehcache
Posted by Unico Hommes <un...@hippo.nl>.
Vadim Gritsenko wrote:
> Unico Hommes wrote:
>
>>
>> SourceForge.net wrote:
>>
>>> Project "ehcache" ('ehcache') has released the new version of
>>> package 'ehcache'.
>>>
>>
>> I believe this was to be our cue for moving ehcache based store to
>> the core and making it our default right? I have just updated our
>> ehcache to the new release version but haven't yet moved it to the
>> core. If noone objects I will move it to the core later.
>
>
> One objection - below.
>
>
>> There still remains one FIXME in the EHCache store implementation
>> though. Method free() hasn't been implemented. AFAIK this one is
>> called by the StoreJanitor to do its work. However, although it works
>> a little different from ours, EHCache has its own kind of janitor
>> mechanism that operates on the basis of time-to-live and time-to-idle
>> expiry strategies. Will this be sufficient or should we try to come
>> up with some sort of implementation of the free() method?
>
>
> No, it won't be sufficient. Janitor checks that JVM is not starving,
> and cache *must* react on low-memory condition regardless of
> time-to-live and other bells-and-wistles.
>
Then what about implementing free() so that it removes a specified
number of elements? Perhaps there is a possibility to find out the LRU
ones. I believe StoreJanitor tries to free memory until the low-memory
condition goes away, so such an implementation would suffice right?
--
Unico
Re: Fw: [SourceForge.net Release] ehcache : ehcache
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Unico Hommes wrote:
>
> SourceForge.net wrote:
>
>> Project "ehcache" ('ehcache') has released the new version of package
>> 'ehcache'.
>>
>
> I believe this was to be our cue for moving ehcache based store to the
> core and making it our default right? I have just updated our ehcache to
> the new release version but haven't yet moved it to the core. If noone
> objects I will move it to the core later.
One objection - below.
> There still remains one FIXME in the EHCache store implementation
> though. Method free() hasn't been implemented. AFAIK this one is called
> by the StoreJanitor to do its work. However, although it works a little
> different from ours, EHCache has its own kind of janitor mechanism that
> operates on the basis of time-to-live and time-to-idle expiry
> strategies. Will this be sufficient or should we try to come up with
> some sort of implementation of the free() method?
No, it won't be sufficient. Janitor checks that JVM is not starving, and
cache *must* react on low-memory condition regardless of time-to-live
and other bells-and-wistles.
In the future Janitor should be hooked into JVM monitoring API:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/MemoryMXBean.html
And then the sky is the limit ;-)
Vadim
> Another thing to keep in mind is that EHCacheStore cannot be used in the
> role of a transient store. This is because it requires entries to be
> Serializable even if it is configured not to be persistence enabled. I
> will file an enhancement request to the ehcache guys like we did with
> JCS at the time, to remove this requirement.
>
> --
> Unico