6 Replies Latest reply on Dec 20, 2006 12:23 PM by manik

    Node clear method bug or problem in my way to use it.

    pitoui
    pitoui Dec 14, 2006 10:17 AM

      Hi,

      We are currenlty evaluating jbosscache and performing some initial tests to see if all required functionality reacts well.
      the problem I found is when you "clear" a Node. the behavior of put is not good. it still return an "old Object" instead of returning null as get is doing

      please see below the sample code to reproduce the problem

      TreeCache _treeCache = new TreeCache();

      PropertyConfigurator config = new PropertyConfigurator(); config.configure( _treeCache,"./testfiles/jbosscache/treecache.xml"
      );

      _treeCache.createService(); // kick start tree cache
      _treeCache.startService(); // kick start tree cache


      Object ret = _treeCache.put("a/b","key","testString"); //ret it null as expected


      ret = _treeCache.get("a/b","key"); // ret is not null as expected

      _treeCache.get("a/b").clear(); // we clear the cache

      ret = _treeCache.get("a/b","key"); //ret it null as expected

      // HERE IS THE PROB
      ret = _treeCache.put("a/b","key","anotherstring"); //ret is not null but equals to testString

      _treeCache.stopService();

      • 2556 Views
      • Tags:
        • 1. Re: Node clear method bug or problem in my way to use it.
          genman
          genman Dec 14, 2006 1:01 PM (in response to pitoui)

          Which version is this? What is in treecache.xml?

            • Actions
          • 2. Re: Node clear method bug or problem in my way to use it.
            pitoui
            pitoui Dec 15, 2006 10:32 AM (in response to pitoui)

            treecache.xml
            <?xml version="1.0" encoding="UTF-8" ?>



            <!-- ==================================================================== -->
            <!-- Defines TreeCache configuration -->
            <!-- ==================================================================== -->

            jboss:service=Naming
            jboss:service=TransactionManager


            <!-- Configure the TransactionManager -->
            org.jboss.cache.DummyTransactionManagerLookup

            <!--
            Node locking scheme :
            PESSIMISTIC (default)
            OPTIMISTIC
            -->
            PESSIMISTIC
            <!--
            Node locking isolation level :
            SERIALIZABLE
            REPEATABLE_READ (default)
            READ_COMMITTED
            READ_UNCOMMITTED
            NONE

            (ignored if NodeLockingScheme is OPTIMISTIC)
            -->
            REPEATABLE_READ

            <!-- Valid modes are LOCAL
            REPL_ASYNC
            REPL_SYNC
            INVALIDATION_ASYNC
            INVALIDATION_SYNC
            -->
            LOCAL

            <!-- Whether each interceptor should have an mbean
            registered to capture and display its statistics. -->
            true

            <!-- Name of cluster. Needs to be the same for all clusters, in order
            to find each other -->
            JBoss-Cache-Cluster


            <!-- UDP: if you have a multihomed machine,
            set the bind_addr attribute to the appropriate NIC IP address
            -->
            <!-- UDP: On Windows machines, because of the media sense feature
            being broken with multicast (even after disabling media sense)
            set the loopback attribute to true
            -->
            <UDP mcast_addr="228.1.2.3" mcast_port="45566" ip_ttl="64" ip_mcast="true"
            mcast_send_buf_size="150000" mcast_recv_buf_size="80000" ucast_send_buf_size="150000"
            ucast_recv_buf_size="80000" loopback="false" />
            <PING timeout="2000" num_initial_members="3" up_thread="false" down_thread="false" />
            <MERGE2 min_interval="10000" max_interval="20000" />
            <FD shun="true" up_thread="true" down_thread="true" />
            <VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false" />
            <pbcast.NAKACK gc_lag="50" max_xmit_size="8192" retransmit_timeout="600,1200,2400,4800" up_thread="false"
            down_thread="false" />
            <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" down_thread="false" />
            <pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false" />
            <FRAG frag_size="8192" down_thread="false" up_thread="false" />
            <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true" />
            <pbcast.STATE_TRANSFER up_thread="false" down_thread="false" />



            <!-- 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
            -->
            5000
            <!-- Number of milliseconds to wait until all responses for a
            synchronous call have been received.
            -->
            10000

            <!-- Max number of milliseconds to wait for a lock acquisition -->
            15000

            <!-- Name of the eviction policy class. -->
            org.jboss.cache.eviction.LRUPolicy

            <!-- Specific eviction policy configurations. This is LRU -->


            5
            <!-- Cache wide default -->

            5000
            1000
            <!-- Maximum time an object is kept in cache regardless of idle time -->
            120



            5000
            1000



            5
            4



            <!-- New 1.3.x cache loader config block -->


            <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
            false

            false

            <!-- we can now have multiple cache loaders, which get chained -->

            org.jboss.cache.loader.FileCacheLoader
            <!-- same as the old CacheLoaderConfig attribute -->

            location=c:\dev\jbosscache

            <!-- whether the cache loader writes are asynchronous -->
            false
            <!-- only one cache loader in the chain may set fetchPersistentState to true.
            An exception is thrown if more than one cache loader sets this to true. -->
            true
            <!-- determines whether this cache loader ignores writes - defaults to false. -->
            false
            <!-- if set to true, purges the contents of this cache loader when the cache starts up.
            Defaults to false. -->
            false


            <!--
            org.jboss.cache.loader.JDBCCacheLoader

            cache.jdbc.driver=com.mysql.jdbc.Driver
            cache.jdbc.url=jdbc:mysql://localhost:3306/jbossdb
            cache.jdbc.user=root
            cache.jdbc.password=

            true
            false
            true
            false

            -->





              • Actions
            • 3. Re: Node clear method bug or problem in my way to use it.
              pitoui
              pitoui Dec 15, 2006 10:37 AM (in response to pitoui)

              the version is:
              1.4.0.SP1 "Jalapeno"

                • Actions
              • 4. Re: Node clear method bug or problem in my way to use it.
                pitoui
                pitoui Dec 15, 2006 10:46 AM (in response to pitoui)

                <?xml version="1.0" encoding="UTF-8" ?>
                &lt;server&gt;
                &lt;classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar" /&gt;

                <!-- ==================================================================== -->
                <!-- Defines TreeCache configuration -->
                <!-- ==================================================================== -->
                &lt;mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache"&gt;
                &lt;depends&gt;jboss:service=Naming&lt;/depends&gt;
                &lt;depends&gt;jboss:service=TransactionManager&lt;/depends&gt;


                <!-- Configure the TransactionManager -->
                &lt;attribute name="TransactionManagerLookupClass"&gt;org.jboss.cache.DummyTransactionManagerLookup&lt;/attribute&gt;

                <!--
                Node locking scheme :
                PESSIMISTIC (default)
                OPTIMISTIC
                -->
                &lt;attribute name="NodeLockingScheme"&gt;PESSIMISTIC&lt;/attribute&gt;
                <!--
                Node locking isolation level :
                SERIALIZABLE
                REPEATABLE_READ (default)
                READ_COMMITTED
                READ_UNCOMMITTED
                NONE

                (ignored if NodeLockingScheme is OPTIMISTIC)
                -->
                &lt;attribute name="IsolationLevel"&gt;REPEATABLE_READ&lt;/attribute&gt;

                <!-- Valid modes are LOCAL
                REPL_ASYNC
                REPL_SYNC
                INVALIDATION_ASYNC
                INVALIDATION_SYNC
                -->
                &lt;attribute name="CacheMode"&gt;LOCAL&lt;/attribute&gt;

                <!-- Whether each interceptor should have an mbean
                registered to capture and display its statistics. -->
                &lt;attribute name="UseInterceptorMbeans"&gt;true&lt;/attribute&gt;

                <!-- Name of cluster. Needs to be the same for all clusters, in order
                to find each other -->
                &lt;attribute name="ClusterName"&gt;JBoss-Cache-Cluster&lt;/attribute&gt;
                &lt;attribute name="ClusterConfig"&gt;
                &lt;config&gt;
                <!-- UDP: if you have a multihomed machine,
                set the bind_addr attribute to the appropriate NIC IP address
                -->
                <!-- UDP: On Windows machines, because of the media sense feature
                being broken with multicast (even after disabling media sense)
                set the loopback attribute to true
                -->
                &lt;UDP mcast_addr="228.1.2.3" mcast_port="45566" ip_ttl="64" ip_mcast="true"
                mcast_send_buf_size="150000" mcast_recv_buf_size="80000" ucast_send_buf_size="150000"
                ucast_recv_buf_size="80000" loopback="false" /&gt;
                &lt;PING timeout="2000" num_initial_members="3" up_thread="false" down_thread="false" /&gt;
                &lt;MERGE2 min_interval="10000" max_interval="20000" /&gt;
                &lt;FD shun="true" up_thread="true" down_thread="true" /&gt;
                &lt;VERIFY_SUSPECT timeout="1500" up_thread="false" down_thread="false" /&gt;
                &lt;pbcast.NAKACK gc_lag="50" max_xmit_size="8192" retransmit_timeout="600,1200,2400,4800" up_thread="false"
                down_thread="false" /&gt;
                &lt;UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10" down_thread="false" /&gt;
                &lt;pbcast.STABLE desired_avg_gossip="20000" up_thread="false" down_thread="false" /&gt;
                &lt;FRAG frag_size="8192" down_thread="false" up_thread="false" /&gt;
                &lt;pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true" /&gt;
                &lt;pbcast.STATE_TRANSFER up_thread="false" down_thread="false" /&gt;
                &lt;/config&gt;
                &lt;/attribute&gt;

                <!-- 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
                -->
                &lt;attribute name="InitialStateRetrievalTimeout"&gt;5000&lt;/attribute&gt;
                <!-- Number of milliseconds to wait until all responses for a
                synchronous call have been received.
                -->
                &lt;attribute name="SyncReplTimeout"&gt;10000&lt;/attribute&gt;

                <!-- Max number of milliseconds to wait for a lock acquisition -->
                &lt;attribute name="LockAcquisitionTimeout"&gt;15000&lt;/attribute&gt;

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

                <!-- Specific eviction policy configurations. This is LRU -->
                &lt;attribute name="EvictionPolicyConfig"&gt;
                &lt;config&gt;
                &lt;attribute name="wakeUpIntervalSeconds"&gt;5&lt;/attribute&gt;
                <!-- Cache wide default -->
                &lt;region name="/_default_"&gt;
                &lt;attribute name="maxNodes"&gt;5000&lt;/attribute&gt;
                &lt;attribute name="timeToLiveSeconds"&gt;1000&lt;/attribute&gt;
                <!-- Maximum time an object is kept in cache regardless of idle time -->
                &lt;attribute name="maxAgeSeconds"&gt;120&lt;/attribute&gt;
                &lt;/region&gt;

                &lt;region name="/org/jboss/data"&gt;
                &lt;attribute name="maxNodes"&gt;5000&lt;/attribute&gt;
                &lt;attribute name="timeToLiveSeconds"&gt;1000&lt;/attribute&gt;
                &lt;/region&gt;

                &lt;region name="/org/jboss/test/data"&gt;
                &lt;attribute name="maxNodes"&gt;5&lt;/attribute&gt;
                &lt;attribute name="timeToLiveSeconds"&gt;4&lt;/attribute&gt;
                &lt;/region&gt;
                &lt;/config&gt;
                &lt;/attribute&gt;
                <!-- New 1.3.x cache loader config block -->
                &lt;attribute name="CacheLoaderConfiguration"&gt;
                &lt;config&gt;
                <!-- if passivation is true, only the first cache loader is used; the rest are ignored -->
                &lt;passivation&gt;false&lt;/passivation&gt;
                &lt;preload&gt;&lt;/preload&gt;
                &lt;shared&gt;false&lt;/shared&gt;

                <!-- we can now have multiple cache loaders, which get chained -->
                &lt;cacheloader&gt;
                &lt;class&gt;org.jboss.cache.loader.FileCacheLoader&lt;/class&gt;
                <!-- same as the old CacheLoaderConfig attribute -->
                &lt;properties&gt;
                location=c:\dev\jbosscache
                &lt;/properties&gt;
                <!-- whether the cache loader writes are asynchronous -->
                &lt;async&gt;false&lt;/async&gt;
                <!-- only one cache loader in the chain may set fetchPersistentState to true.
                An exception is thrown if more than one cache loader sets this to true. -->
                &lt;fetchPersistentState&gt;true&lt;/fetchPersistentState&gt;
                <!-- determines whether this cache loader ignores writes - defaults to false. -->
                &lt;ignoreModifications&gt;false&lt;/ignoreModifications&gt;
                <!-- if set to true, purges the contents of this cache loader when the cache starts up.
                Defaults to false. -->
                &lt;purgeOnStartup&gt;false&lt;/purgeOnStartup&gt;
                &lt;/cacheloader&gt;

                <!--
                org.jboss.cache.loader.JDBCCacheLoader

                cache.jdbc.driver=com.mysql.jdbc.Driver
                cache.jdbc.url=jdbc:mysql://localhost:3306/jbossdb
                cache.jdbc.user=root
                cache.jdbc.password=

                true
                false
                true
                false

                -->
                &lt;/config&gt;
                &lt;/attribute&gt;


                &lt;/mbean&gt;
                &lt;/server&gt;

                  • Actions
                • 5. Re: Node clear method bug or problem in my way to use it.
                  manik
                  manik Dec 20, 2006 12:16 PM (in response to pitoui)

                  paste XML and other code blocks within

                  [ code ]
                  tags.

                    • Actions
                  • 6. Re: Node clear method bug or problem in my way to use it.
                    manik
                    manik Dec 20, 2006 12:23 PM (in response to pitoui)

                    In JBC 1.x, operations should never take place on the Node directly. E.g., don't do

                    cache.get("/a/b/", "key").clear();


                    Instead, do: 
                    cache.removeData("/a/b/");


                    The specific reason why you still see the data is because operations on the nodes do not go through the interceptor stack, so while you may clear the node in memory, you may not clear it in cache loaders, etc.


                      • Actions