How "dynamic" is the TreeCache configuration

[tcherel]

Using TreeCache, it seems that all the configuration parameters can be programmatically set (see list below).

For some of them, I saw a comment saying that if it is modified, the cache must be redeployed.

I am trying to understand the following:

- Does the cache have to be redeployed if any of the properties below are changed?
- What do you mean by "redeploy"? Can a stop/start is enough or does a new instance has to be created?
- In the case, stop/start is enough, is the data present in the cache preserved?

Thanks.

Thomas

setCacheLoader
setCacheLoaderClass
setCacheLoaderConfig
setCacheLoaderShared
setCacheMode
setClusterConfig
setClusterName
setClusterProperties
setEvictionPolicyClass
setEvictionPolicyConfig
setFetchStateOnStartup
setInitialStateRetrievalTimeout
setIsolationLevel
setIsolationLevel
setJndiName
setLockAcquisitionTimeout
setLockLeaseTimeout
setReplQueueInterval
setReplQueueMaxElements
setSyncReplTimeout
setTransactionManagerLookup
setTransactionManagerLookupClass
setUseReplQueue

[ben.wang]

Yes, stop and start "re-deploy" the cache.

-Ben

[tcherel]

Great. Thanks.

[tcherel]

I have the impression that the LRUPolicy is not cleaning its eviction timer properly after multiple stop/start on the TreeCache.

Here is what I am doing on an existing TreeCache:

treeCache.stop
propertyConfigurator.configure(treeCache, [new XML config])
treeCache.start

The new XML config always has the LRU policy eviction policy defined with always the same unique region configured (the default one):

 <!-- Name of the eviction policy class. -->
 <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>

 <!-- Specific eviction policy configurations. This is LRU -->
 <attribute name="EvictionPolicyConfig">
 <config>
 <attribute name="wakeUpIntervalSeconds">60</attribute>
 <!-- Cache wide default -->
 <region name="/_default_">
 <attribute name="maxNodes">1001</attribute>
 <attribute name="timeToIdleSeconds">900</attribute>
 </region>
 </config>
 </attribute>

The only things changing from one XML to the other are the wakeUpIntervalSeconds, maxNodes and timeToIdleSeconds.

If I stop/update/start the tree cache 3 times, I get the following messages upon the third restart:

03:17:16,944 INFO [TreeCache] setEvictionPolicyConfig(): [config: null]
03:17:16,944 INFO [LRUPolicy] Starting eviction policy using the provider: org.jboss.cache.eviction.LRUPolicy
03:17:16,984 INFO [LRUPolicy] Starting a eviction timer with wake up interval of (secs) 60
03:17:16,994 INFO [LRUPolicy] Starting eviction policy using the provider: org.jboss.cache.eviction.LRUPolicy
03:17:16,994 INFO [LRUPolicy] Starting a eviction timer with wake up interval of (secs) 60
03:17:16,994 INFO [LRUPolicy] Starting eviction policy using the provider: org.jboss.cache.eviction.LRUPolicy
03:17:16,994 INFO [LRUPolicy] Starting a eviction timer with wake up interval of (secs) 60
03:17:17,585 INFO [TreeCache] cache mode is local, will not create the channel
03:17:17,585 INFO [TreeCache] Started null

When I look at the number of threads of my JBoss server, I do see an increasing number of threads like the following:

Thread-208" daemon prio=5 tid=0x06dd6e80 nid=0x9b8 in Object.wait() [85af000..85afdb4]
 at java.lang.Object.wait(Native Method)
 - waiting on <0x1626ebc8> (a java.util.TaskQueue)
 at java.util.TimerThread.mainLoop(Timer.java:429)
 - locked <0x1626ebc8> (a java.util.TaskQueue)
 at java.util.TimerThread.run(Timer.java:382)

Am I correct to assume that something is not properly cleaned up upon a stop/update/start or am I missing something?

I am using JBossCache 1.02.

Thanks.

Thomas

[ben.wang]

Thomas,

I have tried to test it against the latest in head with multiple start/stop. And it works for me. Having said that, that portion of code hasn't changed since very early on. So I don't expect 1.02 to be a problem.

Can you verify it on 1.2. And if the problem still persists, please produce a JUnit test case so I can look at it.

Thanks,

-Ben