4 Replies Latest reply on Feb 4, 2011 10:37 AM by sudheerk84

    Clarifications on Distributed mode & L1 caching

    sudheerk84

      HI,

       

      Distributed mode looks very appleaing , but i had a few clarificatiosn on the same

       

      1.  Quoting from the docs

       

      "Doing a PUT would result in at most num_copies remote calls, and doing a GET anywhere in the cluster would result in at most 1 remote call. In reality, num_copies remote calls are made even for a GET, but these are done in parallel and as soon as any one of these returns, the entry is passed back to the caller."

       

      Is there any specific reason to make num_copies remote calls ? . Can i disable this to make only 1 call ? [I know this will not reduce time involved , but surely will reduce network trafic]

       

      2. Quoting from docs [L1 caching]

       

       

      "L1 caching is not free though. Enabling it comes at a cost, and this cost is that every time a key is updated, an invalidation message needs to be multicast to ensure nodes with the entry in L1 invalidates the entry"

       

      So i understand that  this invalidation message is sent and L1 cache becomes dirty(handled by infinispan). So next time i try to access , since L1 cache is dirty it will go across teh network and fetch the latest update.

       

      Based on this can i assume that i will always get the "latest correct value" , even if i give L1 cache timeout as infinite(very high value) ?.

        • 1. Clarifications on Distributed mode & L1 caching
          galder.zamarreno

          Re 1. num_copies remote calls for what? I suppose you're talking about a get()? The problem of reducing that call to just 1 call is that if the node does not respond quickly, you'll have to wait until the call times out before you hit another node. By sending multiple calls we take advantage of the fact that there're multiple copies of the data. So, by making 1 call you could end up making your system work slower, so not sure your suggestion is a good idea. Feel free to open a jira in https://issues.jboss.org/browse/ISPN

           

          Re 2. When a node invalidates the L1 cache of another node, it does it within the context of the modification, so a get(), regardless of whether L1 is on or not, will of course the latest committed value. Remember that get() operations do not require to acquired locks, so hence there's no timeout for them. Also, there's no such thing as L1 cache timeout, there's only lock timeout and locks are only acquired for write ops.

          • 2. Clarifications on Distributed mode & L1 caching
            sudheerk84

            Yes . I was talking about a get.

             

            I was just trying to think to reduce the network traffic.

             

            I understand your point in making num_copies calls. I was thinking if there was an option (an extra attribute)  which could give the user to control this functionality it would be great. But i get your point.

             

            Thanks.

            • 3. Clarifications on Distributed mode & L1 caching
              galder.zamarreno

              As I said, if you feel this is important for you, submit a JIRA and you could even have a go at implementing it? That way you could see whether if it'd actually reduce the network traffic with your own eyes

              • 4. Clarifications on Distributed mode & L1 caching
                sudheerk84

                Thanks Galder

                 

                I have raised a ticket for the same.   https://issues.jboss.org/browse/ISPN-916.

                 

                This is nothing which is blocking me . When i was reading the documentation just thought of it as a configuration worth having.

                 

                When i start stressing the current software which uses infinispan  I will give a try tweaking the settings and the effect it has on teh network :-)