8 Replies Latest reply on May 14, 2008 11:02 AM by lovelyliatroim

    Should be able to use ClusteredCacheLoader with CacheMode.LO

    lovelyliatroim

      Hi guys,

      Just want to discuss this a little more

      http://jira.jboss.com/jira/browse/JBCACHE-1273?page=comments

      Just to quote whats in it


      Not fixing this one since there is a fundamental flaw with allowing a clustered cache loader to work in LOCAL mode. While it does make sense to use the CCL instead of fetching in-memory state on startup (effectively becoming a lazy state transfer mechanism) it doesn't make sense if you are not in a replicated mode since the state you may pull back from the cluster may not be relevant to you.


      Would just like a bit of an expansion on why it doesnt make sense! Example scenario perhaps ;) !!

      Thanks,
      LL





        • 1. Re: Should be able to use ClusteredCacheLoader with CacheMod
          manik

          Well, basically the reason you have a cache loader is so that you have a place to store state that would otherwise be in memory. As such, state in the cache loader would always be state that is relevant to the node in question. E.g., if you were using a file-based cache loader, any state on node A would be in CL-A.

          Now with a CCL this still makes sense if you are using replication, since any state on A is replicated to B and C. So when you look up the cache loader on A for this state, it is accurate to what was originally in A.

          Now if the cluster is not replicated, nodes A, B and C would have different state, potentially using the same Fqns. And using a CCL here could result in meaningless state retrieval.

          E.g.,

          cacheA.put("/a/b/c", "key", "ValueA"); // does not replicate
          cacheB.put("/a/b/c", "key", "ValueB"); // does not replicate
          
          // cache A evicts /a/b/c
          
          // am expecting ValueA if I was using a file cache loader
          // but a CCL will get me ValueB!
          cacheA.get("/a/b/c", "key");
          


          HTH!

          • 2. Re: Should be able to use ClusteredCacheLoader with CacheMod
            lovelyliatroim

            Ok correct me of im wrong here, using a clustered cache loader with replication set to replicate changes is useless because all the values will be replicated anyways to other members. It would only make sense to use it in this mode if you could configure CCL to point to a different cluster which i dont think you can do at the moment.

            So is it fair to say that CCL only makes sense to use when replicating in INVALIDATION mode??


            Now if the cluster is not replicated, nodes A, B and C would have different state, potentially using the same Fqns. And using a CCL here could result in meaningless state retrieval.

            I would say it really depends on your scenario here, if i had static data that doesnt change then i wouldnt really worry about the above happening but i do see that in other scenario´s it would be a problem.

            Another question just on how CCL works. Say i have 2 nodes, A,B. Data items have a life expectancy of 15 mins on each node. So after 15 mins the data item is evicted and if a request comes in and data item isnt there we retrieve from source.
            Each of the nodes are configured to use CCL and every entry made in a cache is flagged as a local entry via
            treeCache.getInvocationContext().getOptionOverrides().setCacheModeLocal(true);
             treeCache.put(nodePath,map);
            


            Now take sequence of events as follows
            1. Node A receives request for data item X
            2. Data Item X, not there, retrieve from source and place in cache.
            3. 14 mins later Node B is asked for data item X,it doesnt have it but node A does and is replicated on B via CCL.
            4. Data Item X is removed from the cache on node A because its 15 minute lifetime expectancy is up.
            5. Node A receives request for data item X,it doesnt have it but node B does. data Item is replicated on to A via CCL. So actually data item X is older than 15 minutes in reality.

            Can the above scenario happen? Will node A keep data Item X for another 15 mins and also have the possibility of the cycle continuing or does NODE B when it receives data Item X know that it must be evicted in 1 minutes time??

            So does jboss cache replicate the timestamp of a data item if it is replicated from one node to another via CCL??

            if not as a possible solution to achieve this could one write their own eviction policy and use an internal ID(member variable) that is transferred from node to node?

            Thanks Manik,
            LL

            • 3. Re: Should be able to use ClusteredCacheLoader with CacheMod
              manik

               

              "lovelyliatroim" wrote:
              Ok correct me of im wrong here, using a clustered cache loader with replication set to replicate changes is useless because all the values will be replicated anyways to other members. It would only make sense to use it in this mode if you could configure CCL to point to a different cluster which i dont think you can do at the moment.

              So is it fair to say that CCL only makes sense to use when replicating in INVALIDATION mode??


              It also makes sense with replication in 2 other scenarios:

              1. Eviction removes stuff from memory on one cache instance, but others may still have it in memory.

              2. You have a running cluster and a new instance joins the cluster, but you don't want to use state transfer to populate the new instance. Instead, you want this to happen lazily, i.e., using a CCL.

              And regarding using the CCL to talk to a different cluster, there is such a thing - it's called the TcpDelegatingCacheLoader. :-)

              • 4. Re: Should be able to use ClusteredCacheLoader with CacheMod
                manik

                 

                "lovelyliatroim" wrote:


                Now take sequence of events as follows
                1. Node A receives request for data item X
                2. Data Item X, not there, retrieve from source and place in cache.
                3. 14 mins later Node B is asked for data item X,it doesnt have it but node A does and is replicated on B via CCL.
                4. Data Item X is removed from the cache on node A because its 15 minute lifetime expectancy is up.
                5. Node A receives request for data item X,it doesnt have it but node B does. data Item is replicated on to A via CCL. So actually data item X is older than 15 minutes in reality.

                Can the above scenario happen? Will node A keep data Item X for another 15 mins and also have the possibility of the cycle continuing or does NODE B when it receives data Item X know that it must be evicted in 1 minutes time??

                So does jboss cache replicate the timestamp of a data item if it is replicated from one node to another via CCL??

                if not as a possible solution to achieve this could one write their own eviction policy and use an internal ID(member variable) that is transferred from node to node?



                This depends on which eviction policy you use. If you use the expiration policy, the expiry time is encoded as data on a node which means it will replicate to B and get evicted at the appropriate time.

                • 5. Re: Should be able to use ClusteredCacheLoader with CacheMod
                  lovelyliatroim

                   


                  This depends on which eviction policy you use. If you use the expiration policy, the expiry time is encoded as data on a node which means it will replicate to B and get evicted at the appropriate time.

                  Thats good to know, i know you can set a max number of nodes on this but can you set a minimum? I have the scenario where if it goes past a certain time i.e its stale then ask data source for data however if data source is not available then use stale data. So does the expiration policy keep a minimum amount of stale data or will it purge all data that has gone past the expiration time?


                  Now to get back to the main point, why it doesnt make sense to run CCL in LOCALMODE. Just referring back to the example given and the comment

                  Now if the cluster is not replicated, nodes A, B and C would have different state, potentially using the same Fqns. And using a CCL here could result in meaningless state retrieval.

                  That really a case if you cared about the state of data between the nodes. For my application, what defines whether to use the value, is the time duration. So I dont care what the value/state is as long as its not older than X mins old. If is older than Xmins old then a new value is retrieved.
                  I do see that it breaks the concept of what a cache loader is if you were allowed to use CCL in LOCAL mode but i do think there is a need to have something like CCL in local mode.

                  • 6. Re: Should be able to use ClusteredCacheLoader with CacheMod
                    manik

                     


                    I do see that it breaks the concept of what a cache loader is if you were allowed to use CCL in LOCAL mode but i do think there is a need to have something like CCL in local mode.


                    Feel free to reopen the JIRA and vote on it then - can't really guarantee when we'll get to it, probably not in the 2.2.0 timeframe. :-) Unless you feel like contributing a patch. It is fairly simple, just that the RpcManagerImpl should start the channel even if in LOCAL mode as long as a CCL is used.

                    • 7. Re: Should be able to use ClusteredCacheLoader with CacheMod
                      manik

                      Re: the expiration policy, it will purge all expired data.

                      • 8. Re: Should be able to use ClusteredCacheLoader with CacheMod
                        lovelyliatroim

                         


                        Re: the expiration policy, it will purge all expired data.

                        Ok thanks Manik, good to know.



                        Feel free to reopen the JIRA and vote on it then - can't really guarantee when we'll get to it, probably not in the 2.2.0 timeframe. :-) Unless you feel like contributing a patch. It is fairly simple, just that the RpcManagerImpl should start the channel even if in LOCAL mode as long as a CCL is used.


                        If i get the time,i´ll have a look!!

                        Thanks Manik,
                        LL