4 Replies Latest reply on Jan 13, 2005 12:21 PM by Ben Wang

    How "dynamic" is the TreeCache configuration

    Thomas Cherel Novice

      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

        • 1. Re: How
          Ben Wang Master

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

          -Ben

          • 2. Re: How
            Thomas Cherel Novice

            Great. Thanks.

            • 3. LRUPolicy is not cleaning its eviction timer properly?
              Thomas Cherel Novice

              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


              • 4. Re: How
                Ben Wang Master

                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