-
Could it be that the disc cache is corrupted? You need to gracefully shutdown the cache; the JVM shutdown hook is not always reliable. You can shutdown reliably using CacheManager.shutdown()
2009-09-16 12:42:30 UTC in ehcache
-
getKeysWithExpirationCheck () will:
1. not count as "activity", so won't affect your semantics
2. will trigger Elements to be removed from the cache (the memory cache is not cleaned up routinely for performance reasons)
I have an application with similar requirements. Our implementation was to use a cache with eternal=true and we use the HttpSessionBindingListener to remove...
2009-09-14 21:34:29 UTC in ehcache
-
Blocking Cache is only designed to work within a single VM (single CacheManager actually). It is implemented using in-memory semaphores which are not visible to another VM.
The distributed features of Ehcache propogate changed cache values to other peers; there is no communication to other nodes, for instance, when a node is "building" a cache value so you risk the chance that...
2009-09-11 06:46:32 UTC in ehcache
-
In order that someone can answer the question, please state which distribution mechanism you use to communicate between Cache Managers: there are several, e.g. RMI, JGroups, JMS and which version of the core product you use and proposed version you are upgrading to. Depending on which distribution mechanism you are using, e.g. JMS, this is packaged separately so will have a different version...
2009-09-06 20:09:54 UTC in ehcache
-
AFAIK you are correct; you can listen to cache put events (see http://ehcache.org/documentation/cache_event_listeners.html) but you cannot distinguish that they came from a peer or the current cache. However this is easily achieved, here are two options for you to consider:
1. Make the value passed in the Element are rich object that includes the identifier of the JVM/host/peer that created...
2009-09-04 06:39:44 UTC in ehcache
-
Have you subclassed Element? Assuming not, which Element constructor are you using? If we cannot see anything unusual from this, please can you create a self-contained class that exhibits the issue?.
2009-08-26 14:56:35 UTC in ehcache
-
Have you overriden the hashCode() or equals() methods or implemented Comparable on the object that represents your key? If so, can you post those code snippets here?.
2009-08-26 12:50:24 UTC in ehcache
-
By default, the data is not stored on the disc. You need to:
1. adjust your ehcache.xml (see http://ehcache.sourceforge.net/documentation/storage_options.html#DiskStore) to specify where your want your disc cache and you need to set the attribute eternal="true"
2. you need to ensure Ehcache is gracefully shut down. Use this:
cacheMgr.shutdown();.
2009-08-17 14:26:42 UTC in ehcache
-
Ah yes, I see - my previous suggestion only did an expiry check during the refresh cycle on the "refresh thread".
If you want to ensure every cache GET runs an expiry check you need to override get(..) (but of course you can still do that if you subclass SelfPopulatingCache rather than BlockingCache)
2009-07-24 06:29:07 UTC in ehcache
-
Is this what you are looking for?
A general description of distributed caching
http://ehcache.sourceforge.net/documentation/distributed_design.html
RMI specifics
http://ehcache.sourceforge.net/documentation/distributed_caching_with_rmi.html
(Note that there no notion in ehcache of a master/slave - each node is an equal peer)
2009-07-21 21:37:56 UTC in ehcache
