11 Replies Latest reply on Jul 5, 2005 9:01 PM by ben.wang

    How does

    roginsky

      A complete TreeCache newby here, so sorry if the questions are less than deep and meaningful. Also sorry for the long post...
      I'm experimenting with the TreeCacheAop, using "replSync-service.xml" from JBossCache-1.2.1.zip file.
      After I evict a node, I expect it to be removed from the memory cache, but not from the permanent backstore.
      When I call "get", I expect it to look first in the memory cache, and if the node is not there, load it from the backstore.
      However, when I evict a node, and then try to get it, I get null. The node seems to be in the backstore (I see files), it's loaded successfully when I stop and restart the service. Does it mean that if a node is not accessed for a long time and is evicted, I won't be able to "get" it, unless I explicitely load it from the backstore?

      When I remove a node, I expect it to be removed from the memory and the backstore (otherwise, how is it different from "evict"?). However, it looks like the node remains in the backstore. Is there any way to remove data from the backstore?

      Thanks for your help!

        • 1. Re: How does
          belaban

          I suggest you
          (a) look at the FileCacheLoaderTest for examples and
          (b) update to 1.2.2

          • 2. Re: How does
            roginsky

            Thank you Bela!
            I tried running the testEvictionWithCacheLoader2 from the CacheLoaderTestBase class, and it indeed works. Then I modified it like this (because this is the functionality I'm looking for):
            cache.putObject("/first/second/third", "val1"); // stored in cache loader
            cache.evict(Fqn.fromString("/first/second/third")); // removes node, because there are no children
            assertFalse(cache.exists("/first/second/third"));
            assertTrue(cache.exists("/first/second"));
            assertTrue(cache.exists("/first"));
            String val=(String)cache.getObject("/first/second/third"); // should be loaded from cache loader
            assertEquals("val1", val);
            assertTrue(cache.exists("/first/second/third"));
            assertTrue(cache.exists("/first/second"));
            assertTrue(cache.exists("/first"));

            getObject returns null, so bolded assertEquals fails. Am I not understanding how the Aop tree works with objects? I tried adding cache.load("/first/second/third") just before cache.getObject(), and it didn't help.

            Also, when I downloaded 1.2.2 zip file, the jboss-jmx.jar wass missing org.jboss.mx.util.JBossNotificationBroadcasterSupport class, so I had to get this jar from CVS.

            • 3. Re: How does
              roginsky

              P.S. It appears that for the TreeCacheAop evict() causes complete removal of the node from the backstore. The regular TreeCache doesn't do it. Is this the expected behavior? I though eviction only affects the memory cache, but not the backstore. Is there any configuration that would prevent it from happening?

              P.P.S. If I use exactly the same Aop cache and configuration, but instead of using putObject(fqn, pojp) API, use put(fqn, key, pojo), the backstore node doesn't get removed during "evict()" call.

              Thank you for your help and for getting back to me so quickly after my first post.

              • 4. Re: How does eviction work for Aop tree
                roginsky

                I hope someone is reading it... or am I writing to myself?
                Anyway, I think this is the problem code (from TreeCacheAop.java):

                public void evict(Fqn fqn) throws CacheException {
                // We will remove all children nodes as well since we assume all children nodes are part
                // of this "object" node.
                if(isAopNode(fqn)) {
                if(log.isDebugEnabled()) {
                log.debug("evict(): evicting whole aop node " +fqn);
                }
                // _remove(null, fqn, create_undo_ops, false);
                // TODO Why do we not want to remove the interceptor??? I think we should.
                // Because if we remove it, the caller has no idea that it has been taken off.
                // She will still think that caching is in effect. But this returns null value from cache.
                // What's is a good policy?
                boolean removeCacheInterceptor = false;
                _removeObject(fqn, removeCacheInterceptor);
                } else {
                super.evict(fqn);
                }
                }

                Is it possible to remove the interceptor only for this one call (_removeObject) and then put it back? Seems like that would be the right thing to do.

                • 5. Re: How does

                  Yes, we are reading. :-)

                  This looks like a bug. Can you open up a Jira issue under JBossCache and please assign it to me.

                  Thanks,

                  -Ben

                  • 6. Re: How does
                    roginsky

                    Oh, thank you, thank you,thank you!

                    You guys are awesome, responding so quickly to so many people (not to mention your great products and impressive documentation)! I only wondered whether anyone was reading because I had no idea how you managed it.

                    I opened an issue, but I don't have the authority to assign it.
                    http://jira.jboss.com/jira/browse/JBCACHE-135

                    Thanks again!

                    • 7. Re: How does
                      mohamedj

                      Is there any idea when this will be fixed?

                      • 8. Re: How does

                        Probably within next two weeks.

                        -Ben

                        • 9. Re: How does
                          mohamedj

                          Great news! Is there a scheduled build release coming soon after?

                          • 10. Re: How does

                            Release 1.2.4 is scheduled at the end of August for now. But you are welcome to try out the development version once I get it fixed.

                            Stay tune,

                            -Ben

                            • 11. Re: How does

                              OK, I have checked in the code. You can grab the cvs and build for yourself if you want. I have added a new test case FileCacheLoaderAopTest to test it out.

                              Release 1.2.4 is scheduled for end of August now.

                              -Ben