4 Replies Latest reply on Jun 21, 2016 10:00 AM by tomas11

    Configuration options for special case of Inifnispan behaving

    tomas11

      Hi

       

      I would like to ask if there is option/configuration with which would Infinispan cluster behave following:

       

      - have 1 copy of each object in cluster

      - object is located always on node where this was put

      - access to this object is available from all nodes in cluster

       

      So basically have only shared access and persistent location of the objects. Maybe it goes little bit against even data distribution in cluster but that would be acceptable.

       

      We were playing little bit with disabling state-transfer but seems this is not straight path to make id done. Can this be achieved somehow with different configuration?

       

      Thanks for suggestions

      Tomas

        • 1. Re: Configuration options for special case of Inifnispan behaving
          rvansa

          Distributed mode with numOwners=1 (default is 2) should make the object to be held in single copy, and KeyAffinityService will help you to place the object on local node. You won't be able to choose the key arbitrary, though.

          • 2. Re: Configuration options for special case of Inifnispan behaving
            tomas11

            Hi Radim

             

            numOwners=1 is fine. Also KeyAffinityService looks promising however what with Topology change? From documentation it comes - When a topology change takes place the key ownership from the KeyAffinityService might change.

             

            Can we secure that when once is object placed to its node it never will change location? Than it would be what we are looking for.

            • 3. Re: Configuration options for special case of Inifnispan behaving
              rvansa

              Topology change happens when a node join or leaves. What should happen if the node 'owning' that record dies, should the record die as well? Well, with numOwners=1, upon a crash you'd lose something, so it's probably the desired behaviour... Generally Infinispan is designed with not losing data in mind The case when you can actually lose data is covered by invalidation mode cache loading data from external shared source (such as DB), but there you can't read other node's data - you just load it again from DB and if you update the underlying source, you invalidate records in the other nodes.

               

              So, I think that if you want to hack it the way you want, you need to code your own implementation of ConsistentHashFactory, and set it in configuration (not sure if that's possible through XML, but programmatically it's in clustering().hash().consistentHashFactory()). This implementation will statically assign segments to nodes, never changing owner of (used - see below) segment.

               

              Changing number of segments is not possible in runtime AFAIK, so you should set some expectation on max cluster size (e.g. 256 nodes), set this number of segments and assign each node one segment. The segments for which there's no node could be assigned to anyone, you wouldn't use them - each node would generate keys so that they end up locally (KeyAffinityService should inspire you).

               

              Does this make sense to you? Sorry for not providing any OOTB solution, but there's the invalidation cache. And if you manage to get that working, contributions are always welcome

              • 4. Re: Configuration options for special case of Inifnispan behaving
                tomas11

                Yes when node crash and data would get lost in would be ok in our scenario.

                 

                Ok I see where you are pointing me at So custom ConsistentHashFactory should be the way. I will need to look deeper in implementation but thanks for hints.