9 Replies Latest reply on Jun 9, 2011 2:20 AM by gaprashanth

    Important Questions in Infinispan

    gaprashanth
      1. How do max entries in a named cache  translate into size? And does Infinispan request the kernel to NOT PAGE OUT the cache memory allocated?
      2. How to turn on the grid in Infinispan. Is it same as configuring the DISTRIBUTION mode of cluster?
      3. Is INFINISPAN programmatic API supported on the client-server mode of deployment like Hot Rod client server also? Basically how to modify the cache settings dynamically on a client-server model? From the experimentations it seems to be supported only on the EmbeddedCacheManager and not on RemoteCachemanager.
      4. How to dynamically change the cache attributes for the entire named cache at run-time? Basically how to change the TTL for the entire named cache in one step?
      5. Assuming that there is a cluster of nodes all having the EmbdeddedCache replicated across the cluster. If the Cache is restarted on any of the nodes, how to determine that that the restarted cache has loaded all its content from the other nodes?
      6. Is there support for higher/lower watermarks for flushing the data from the memory to the persistent store due to eviction? Once the eviction starts as the max entries are reached, how long the eviction runs?
      7. For running the Infinispan as embedded cache on the same JVM of the App server, how to determine/limit the max heap size consumed by the Infinispan? This is required as the JVM is shared by the App server also and the cache and not interfere with the memory allocated for the App server.
        • 1. Re: Important Questions in Infinispan
          galder.zamarreno

          Re 1. There's no relationship between max entries and their size. Max entries is just the number of entries. Figuring out the size of your objects in Java is not trivial and the options available can be costly, hence why this has not been implemented.

           

          Re: NOT PAGE OUT -> This is a java based grid, we can't send instructions to the kernel

           

          Re 2. Dunno what you mean by "turn on the grid"

           

          Re 3. Indeed, as you saw remote clients cannot execute remote configuration changes, or create new configs.

           

          Re 4. Not configurable at runtime.

           

          Re 5. If state transfer is configured, the cache will on restart bring all the state from the coordinator. You won't be able to use the Cache instance until the state transfer has finished.

           

          Re 6. There're no watermarks. It will run until the cache is below the max entries but might go further if there're entries that might be expired (due to lifespan or max idle being exceeded)

           

          Re 7. Not possible yet.

          • 2. Re: Important Questions in Infinispan
            gaprashanth

            Hi Galder,

            Thanks for the answers.  I am having one more question on the behaviour of  cluster wide locking of the data in case of a grid.

             

            Assume a cache cluster having three nodes N1, N2 and N3 configured for distribution. So what happens if the same cache key (key1) is being inserted at the same time on the two nodes N1 and N2? Since key 1 is new to the cache, whether both the nodes end up adding it to their respective local in-memory caches. So do we end up in having data duplication. Probabaly the clusterwide locking can not be used since the key, key 1 is new to the cache ?

             

            Also I am getting confused with the options of provided on MVCC and eager locking.  While running a distributed cache in the cluster and with the reads/writes happening on all the nodes, which one should be used or both.

             

            Please excuse me for any wrong assumptions made here, as my knowledge is limited on this topic.

            • 3. Re: Important Questions in Infinispan
              mircea.markus

              Assume a cache cluster having three nodes N1, N2 and N3 configured for distribution. So what happens if the same cache key (key1) is being inserted at the same time on the two nodes N1 and N2? Since key 1 is new to the cache, whether both the nodes end up adding it to their respective local in-memory caches. So do we end up in having data duplication. Probabaly the clusterwide locking can not be used since the key, key 1 is new to the cache ?

              There's no relation between the node where data is inserted and where it is stored. Our distribution is based on consistent hashing which makes sure that every node deterministically stores the data in one of its pears. 

               

              Also I am getting confused with the options of provided on MVCC and eager locking.  While running a distributed cache in the cluster and with the reads/writes happening on all the nodes, which one should be used or both.

              Depends of what your consistency requirements are. If you use eager locking then, during a transaction, if you write on a key nobody else is able to write same key before the transaction compleats.

              • 4. Re: Important Questions in Infinispan
                gaprashanth

                There's no relation between the node where data is inserted and where it is stored -

                     While two different transactions are attempting add the 'key1' on two nodes concurrently, so Infinispan detects it and makes sure that key is created only on one node and all other nodes will know about its location based on the deterministic approach ?

                 

                How do we enable MVCC, is it enabled by default?

                 

                    

                 

                • 5. Re: Important Questions in Infinispan
                  mircea.markus

                       While two different transactions are attempting add the 'key1' on two nodes concurrently, so Infinispan detects it and makes sure that key is created only on one node and all other nodes will know about its location based on the deterministic approach ?

                  yes.

                  How do we enable MVCC, is it enabled by default?

                  yes. It's the only concurency control mechanism available in infinispan.

                  • 6. Re: Important Questions in Infinispan
                    gaprashanth

                    Thanks.

                     

                    In case of MVCC, assume that node N1 started a transaction T1 first and was about to update some entry on a key. Now if node N2 starts transaction T2 and attempts to update a different value, Does MVCC rejects T2 as T1 is not complete yet ? At the end, the key only gets updated by T1 of N1. Now what happens to the T2 ? is it a failed transaction ?  Or the T2 is also allowed to make its update with a version number and finally the key actually gets the value of T2 as it had the latest timestamp?

                     

                    Is eager locking a more strict way of locking the keys compared to MVCC?   I was just curiuos to know the difference between eager locking and MVCC

                    • 7. Re: Important Questions in Infinispan
                      kodadma

                      Regarding Q.2:

                       

                      In Linux you can lock entire process in a memory:

                       

                      mlockall (MCL_CURRENT | MCL_FUTURE)

                       

                      You can use JNA to call this function directly from your Java application

                      There are some additional requirements though - you can Google them.

                      • 8. Re: Important Questions in Infinispan
                        mircea.markus

                        In case of MVCC, assume that node N1 started a transaction T1 first and was about to update some entry on a key. Now if node N2 starts transaction T2 and attempts to update a different value, Does MVCC rejects T2 as T1 is not complete yet ? At the end, the key only gets updated by T1 of N1. Now what happens to the T2 ? is it a failed transaction ?  Or the T2 is also allowed to make its update with a version number and finally the key actually gets the value of T2 as it had the latest timestamp?

                        I presume T1 and T2 updated the same key. Both transactions complete, just that one has to wait for the other to finish before it applies it changes. That's defined by transactions' isolocation level.

                        • 9. Re: Important Questions in Infinispan
                          gaprashanth

                          I have one question on the Hot Rod Client-server mode. Though, EmbeddedCache looks attractive and makes the cache faster, I guess it is of no use if your application is to sesnitive for performance and you can't take risk with GC pauses.

                          So we have decided to go for the remote cache beyond doubt.

                           

                          But we also have a requirement to programmatically tocuh the configurations of Infnispan and not to make use of any of its physical configuration files. This is because, we have requirements to modify the behaviuor of a named cache at run-time like TTL, Idletime etc.  It was said in another discussion that Infnispan doesn't support this freature in the client server modules. So how do we go about this.

                           

                          Should we deploy our own cache client in a separate JVM other than our application JVM and make our application talk to this client using RMI protocol. Our client would still talk to the Infinispan cache in embedded mode only ?

                           

                          Any other suggestions are welcome.