|
Memory cleanup thread
>From what I can tell, there is no
memory cleanup thread for performance reasons, but why not have it as
an option for people that want it? For instance a
memoryExpiryThreadIntervalSeconds config option that defaults to
'never'. I find myself having to setup a timer for all my caches and
calling evictExpiredElements, but it should really just be part of
ehcache itself. Regards, Travis
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
|
|
Re: Memory cleanup thread
Travis
Ehcache started as a fork of JCS. JCS had that feature.
Why do you evict elements? There is very little cost in eviction on get if the element is expired or evict on overflow. If its to save memory, you have to tune for the worst case of full caches anyway.
On 14/05/2008, at 10:53 AM, Travis Reeder wrote: >From what I can tell, there is no memory cleanup thread for performance reasons, but why not have it as an option for people that want it? For instance a memoryExpiryThreadIntervalSeconds config option that defaults to 'never'. I find myself having to setup a timer for all my caches and calling evictExpiredElements, but it should really just be part of ehcache itself.
Regards,
Travis
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
Regards
Greg Luck
skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
|
|
Re: Memory cleanup thread
One reason is to reduce memory usage for things that aren't needed, but I agree that you should tune the cache to only hold as much as you need. But another important reason I had to do trigger it manually was because I wanted the cache listeners to know about evicted elements so they can do some database updates. For instance, when an element gets removed, I want to update the database with that elements data. The problem is, if they never expire/get evicted, then the listeners will never receive the event and therefore the database will never get updated. So I had to setup a timer to evictExpiredElements so the CacheListeners can handle the events.
Make sense? On Thu, May 15, 2008 at 12:01 AM, Greg Luck < gluck@...> wrote:
Travis
Ehcache started as a fork of JCS. JCS had that feature.
Why do you evict elements? There is very little cost in eviction on get if the element is expired or evict on overflow. If its to save memory, you have to tune for the worst case of full caches anyway.
Regards
Greg Luck
skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
|
|
Re: Memory cleanup thread
Just ran into another good reason to have a cleanup thread for the memory store. If you have something in a cache that references other objects (lets say a Collection) which may also be in another cache, those referenced objects will also never be able to get garbage collected even though the Collection would have expired.
Eg: Cache A holds object type X. Cache B holds Collections of object type X, but related to a specific entity, a user for instance. While that user is using the system, we can quickly grab the Collection out of Cache B, but lets say the user leaves and the collection would have expired, but obviously never get removed because there is no thread cleaning it up. So now even if Cache A overflows and starts cleaning itself up, those objects will never actually get garbage collected.
So that's two very important reasons for having a memory cleanup thread (second one below). Also, it seems to me that the thread would have zero performance effect unless it were enabled so the "it's for performance reasons" argument doesn't really hold weight.
Travis On Thu, May 15, 2008 at 11:59 PM, Travis Reeder <treeder@...> wrote:
One reason is to reduce memory usage for things that aren't needed, but I agree that you should tune the cache to only hold as much as you need.
But another important reason I had to do trigger it manually was because I wanted the cache listeners to know about evicted elements so they can do some database updates. For instance, when an element gets removed, I want to update the database with that elements data. The problem is, if they never expire/get evicted, then the listeners will never receive the event and therefore the database will never get updated. So I had to setup a timer to evictExpiredElements so the CacheListeners can handle the events.
Make sense?On Thu, May 15, 2008 at 12:01 AM, Greg Luck < gluck@...> wrote:
Travis
Ehcache started as a fork of JCS. JCS had that feature.
Why do you evict elements? There is very little cost in eviction on get if the element is expired or evict on overflow. If its to save memory, you have to tune for the worst case of full caches anyway.
Regards
Greg Luck
skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
|
|
 Re: Memory cleanup thread
Travis
Ok, Why don't you do this in a patch. On 09/08/2008, at 9:25 AM, Travis Reeder wrote: Just ran into another good reason to have a cleanup thread for the memory store. If you have something in a cache that references other objects (lets say a Collection) which may also be in another cache, those referenced objects will also never be able to get garbage collected even though the Collection would have expired. Eg: Cache A holds object type X. Cache B holds Collections of object type X, but related to a specific entity, a user for instance. While that user is using the system, we can quickly grab the Collection out of Cache B, but lets say the user leaves and the collection would have expired, but obviously never get removed because there is no thread cleaning it up. So now even if Cache A overflows and starts cleaning itself up, those objects will never actually get garbage collected. So that's two very important reasons for having a memory cleanup thread (second one below). Also, it seems to me that the thread would have zero performance effect unless it were enabled so the "it's for performance reasons" argument doesn't really hold weight. Travis On Thu, May 15, 2008 at 11:59 PM, Travis Reeder <treeder@...> wrote: One reason is to reduce memory usage for things that aren't needed, but I agree that you should tune the cache to only hold as much as you need.
But another important reason I had to do trigger it manually was because I wanted the cache listeners to know about evicted elements so they can do some database updates. For instance, when an element gets removed, I want to update the database with that elements data. The problem is, if they never expire/get evicted, then the listeners will never receive the event and therefore the database will never get updated. So I had to setup a timer to evictExpiredElements so the CacheListeners can handle the events.
Make sense?On Thu, May 15, 2008 at 12:01 AM, Greg Luck < gluck@...> wrote: Travis
Ehcache started as a fork of JCS. JCS had that feature.
Why do you evict elements? There is very little cost in eviction on get if the element is expired or evict on overflow. If its to save memory, you have to tune for the worst case of full caches anyway.
Regards
Greg Luck
skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
Regards
Greg Luck
skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
|
|
Re: Memory cleanup thread
Created patch here and posted here. http://sourceforge.net/tracker/index.php?func=detail&aid=2046973&group_id=93232&atid=603561
Travis On Fri, Aug 8, 2008 at 4:59 PM, Greg Luck <gluck@...> wrote:
Travis
Ok, Why don't you do this in a patch. On 09/08/2008, at 9:25 AM, Travis Reeder wrote:
Just ran into another good reason to have a cleanup thread for the memory store. If you have something in a cache that references other objects (lets say a Collection) which may also be in another cache, those referenced objects will also never be able to get garbage collected even though the Collection would have expired.
Eg:
Cache A holds object type X.
Cache B holds Collections of object type X, but related to a specific entity, a user for instance. While that user is using the system, we can quickly grab the Collection out of Cache B, but lets say the user leaves and the collection would have expired, but obviously never get removed because there is no thread cleaning it up. So now even if Cache A overflows and starts cleaning itself up, those objects will never actually get garbage collected.
So that's two very important reasons for having a memory cleanup thread (second one below). Also, it seems to me that the thread would have zero performance effect unless it were enabled so the "it's for performance reasons" argument doesn't really hold weight.
Travis
On Thu, May 15, 2008 at 11:59 PM, Travis Reeder <treeder@...> wrote:
One reason is to reduce memory usage for things that aren't needed, but I agree that you should tune the cache to only hold as much as you need.
But another important reason I had to do trigger it manually was because I wanted the cache listeners to know about evicted elements so they can do some database updates. For instance, when an element gets removed, I want to update the database with that elements data. The problem is, if they never expire/get evicted, then the listeners will never receive the event and therefore the database will never get updated. So I had to setup a timer to evictExpiredElements so the CacheListeners can handle the events.
Make sense?On Thu, May 15, 2008 at 12:01 AM, Greg Luck < gluck@...> wrote:
Travis
Ehcache started as a fork of JCS. JCS had that feature.
Why do you evict elements? There is very little cost in eviction on get if the element is expired or evict on overflow. If its to save memory, you have to tune for the worst case of full caches anyway.
Regards
Greg Luck
skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
Regards
Greg Luck
skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
|
|
Re: Memory cleanup thread
Created patch (with unit test) here and posted here. http://sourceforge.net/tracker/index.php?func=detail&aid=2046973&group_id=93232&atid=603561
Travis On Fri, Aug 8, 2008 at 4:59 PM, Greg Luck <gluck@...> wrote:
Travis
Ok, Why don't you do this in a patch. On 09/08/2008, at 9:25 AM, Travis Reeder wrote:
Just ran into another good reason to have a cleanup thread for the memory store. If you have something in a cache that references other objects (lets say a Collection) which may also be in another cache, those referenced objects will also never be able to get garbage collected even though the Collection would have expired.
Eg:
Cache A holds object type X.
Cache B holds Collections of object type X, but related to a specific entity, a user for instance. While that user is using the system, we can quickly grab the Collection out of Cache B, but lets say the user leaves and the collection would have expired, but obviously never get removed because there is no thread cleaning it up. So now even if Cache A overflows and starts cleaning itself up, those objects will never actually get garbage collected.
So that's two very important reasons for having a memory cleanup thread (second one below). Also, it seems to me that the thread would have zero performance effect unless it were enabled so the "it's for performance reasons" argument doesn't really hold weight.
Travis
On Thu, May 15, 2008 at 11:59 PM, Travis Reeder <treeder@...> wrote:
One reason is to reduce memory usage for things that aren't needed, but I agree that you should tune the cache to only hold as much as you need.
But another important reason I had to do trigger it manually was because I wanted the cache listeners to know about evicted elements so they can do some database updates. For instance, when an element gets removed, I want to update the database with that elements data. The problem is, if they never expire/get evicted, then the listeners will never receive the event and therefore the database will never get updated. So I had to setup a timer to evictExpiredElements so the CacheListeners can handle the events.
Make sense?On Thu, May 15, 2008 at 12:01 AM, Greg Luck < gluck@...> wrote:
Travis
Ehcache started as a fork of JCS. JCS had that feature.
Why do you evict elements? There is very little cost in eviction on get if the element is expired or evict on overflow. If its to save memory, you have to tune for the worst case of full caches anyway.
Regards
Greg Luck
skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
Regards
Greg Luck
skype: gregrluck yahoo: gregrluck mobile: +61 408 061 622
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
ehcache-list mailing list
ehcache-list@...
https://lists.sourceforge.net/lists/listinfo/ehcache-list
|
