i am using jboss cache to cache string objects with a key. these are basically xml string but stored as plain java strings. I have written a customLRUPolicy wherein at the end of day when maxage is reached (86400 seconds) the object is removed from cache rather than evict. otherwise no difference between wat i have patched on LRUPolicy.
so insted of calling Cache.evict your CustomLRUPolicy calls Cache.remove, right?
There are two possibilities of doing that, one would be Cache.remove or CacheImpl._remove
For , the call goes through the interceptor chain including CacheStore interceptor, which would also remove the node from the persistent storage. This results in not having the data in memory both and disk... Can you please send the used cache configuration file.
 is not recommended at all as it violates cache internals (e.g. transaction locks etc)
Yes u are right, i call remove instead of evict when maxage is reached.
i am using the Jboss Cache 1.4 , i think jalapeno...so that wud be a remove call on TreeCache. This wud be the (2) u were talking abt ?
my cache config file as in u mean the jboss-service.xml ?
<?xml version="1.0" encoding="UTF-8"?>
<PING timeout="2000" num_initial_members="3"
<TCPPING initial_hosts="10.1.30.62,10.1.30.66" port_range="3" timeout="3500" num_initial_members="3" up_thread="true" down_thread="true"/>
<MERGE2 min_interval="10000" max_interval="20000"/>
<FD shun="true" up_thread="true" down_thread="true"
<VERIFY_SUSPECT timeout="3000" num_msgs="3"
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
Node locking level : SERIALIZABLE
<!-- Name of cluster. Needs to be the same for all clusters, in order
to find each other
<!-- JGroups protocol stack properties. Can also be a URL,
The max amount of time (in milliseconds) we wait until the
initial state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
<!-- New 1.3.x cache loader config block -->
<!-- Eviction Policy Configuration -->
<!-- Specific eviction policy configurations. This is LRU -->
<!-- Cache wide default -->
One more thing i noticed. i turned off the caccheloader completely, i.e no bdbjeloader. so when the evict is called it is evicted from in-memory. In this case once my operation is complete and eviction happns the jvm comes back to the state before i started. so here are my results :
1. withcacheloader(bdbje) and CustomLRUPolicy(evicts from cache for timetolive, calls remove on Treecache for maxage) - memory hits very high peak and doesnt come down 1.1G
2. same as 1 only very low time to live, so evict will be called almost instantly , but high max age so the nodes are there in persistent storage - memory usage similar to 1.
3. no cache at all - memory usage is minimum about 100M continously
4. with cache and no cacheloader, hence evicted will be lost - goes up to 800M but on eviction comes down to 100M again.
ok, now i had a look at the BDbje code and noticed that it takes about 60 percent of the total memory, which is 60 percent of the 1024 i allocated in Xmx. so it caches all the objects already present in jbosscache and the copy of all this i s also there in the persistent storage.
now je is supposed to take in a je.properties when forming the environment , but looking at bdbjecacheloader we pass the envdir from there as java.io.tmpdir which is /tmp/ directory on unix systems. this is the reason why my putting je.properties everywhere(conf, lib, bin) didnt make any difference to the bdbjeconfig(it kept starting with cachepercent at 60 )
patching the BdbjeCacheloader to set the percentage of memory berkleydb should take for its inmemory cache to a bare minimum solves the problem.
in the method start():
i added this saying bdbje to use only 5 percent of total memory for its inmemory and put the whole thing in persistent.
now everything works fine.the maxmemory used comes down from 1G to 500M and once the process is over gc kicks in and brings it down to 160M. previously it never even came down from 1G
Hope this helps!!