Uploaded image for project: 'Infinispan'
  1. Infinispan
  2. ISPN-4296

Restore predefined cache limitation for Hot Rod servers

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

      Even after asymmetric cluster support was implemented, each node still does not know which other nodes contain which caches. The coordinator of the cluster knows, but no one else. This is because the aim has never really been to have different nodes containing different caches, but more about making sure that caches can be started lazily. With this in mind, the limitation in ISPN-833 will be reinstated.

      Being able to work only with predefined caches also simplifies a solution for ISPN-3530 because we can safely assume that all servers contain the defined caches. Each cache might have a different consistent hash (see dev list discussion on why this can easily happen - http://lists.jboss.org/pipermail/infinispan-dev/2014-April/014870.html) but at least knowing that the nodes that have it is the same makes it easier to come up with a solution.

      Finally, restoring the limitation avoids other can of worms such as the edge cases discovered by Jakub in ISPN-4212.

            [ISPN-4296] Restore predefined cache limitation for Hot Rod servers

            Gustavo Fernandes (Inactive) added a comment - - edited

            The limitation is restored successful only for REPL caches, as shown in ClientAsymmetricClusterTest

            But for DIST caches, a nonexistent cache is started anyway in order to get hold of the ConsistentHash to write the topology update, as shown in Encoder2x
            If in the test we change from REPL to DIST, it fails, not throwing CacheNotFoundException anymore.

            Was this intentional? Shouldn't DIST behave the same way as REPL?

            Gustavo Fernandes (Inactive) added a comment - - edited The limitation is restored successful only for REPL caches, as shown in ClientAsymmetricClusterTest But for DIST caches, a nonexistent cache is started anyway in order to get hold of the ConsistentHash to write the topology update, as shown in Encoder2x If in the test we change from REPL to DIST, it fails, not throwing CacheNotFoundException anymore. Was this intentional? Shouldn't DIST behave the same way as REPL?

            RH Bugzilla Integration added a comment -

            Tristan Tarrant <ttarrant@redhat.com> changed the Status of bug 1110686 from NEW to ON_QA

            RH Bugzilla Integration added a comment - Tristan Tarrant <ttarrant@redhat.com> changed the Status of bug 1110686 from NEW to ON_QA

            Galder Zamarreño added a comment -

            Just updated the JIRA to add a missing link to the consistent hash function differences between two caches. The javadoc for SyncConsistentHashFactory contains a very good explanation on how two identical caches, with the same topologies, can end up having different consistent hashes.

            Galder Zamarreño added a comment - Just updated the JIRA to add a missing link to the consistent hash function differences between two caches. The javadoc for SyncConsistentHashFactory contains a very good explanation on how two identical caches, with the same topologies, can end up having different consistent hashes.

              rh-ee-galder Galder Zamarreño
              rh-ee-galder Galder Zamarreño
              Archiver:
              rhn-support-adongare Amol Dongare

                Created:
                Updated:
                Resolved:
                Archived: