[
https://issues.jboss.org/browse/ISPN-4296?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-4296:
----------------------------------------
Just updated the JIRA to add a missing link to the consistent hash function differences
between two caches. The [javadoc for
SyncConsistentHashFactory|https://github.com/infinispan/infinispan/blob/m...]
contains a very good explanation on how two identical caches, with the same topologies,
can end up having different consistent hashes.
Restore predefined cache limitation for Hot Rod servers
-------------------------------------------------------
Key: ISPN-4296
URL:
https://issues.jboss.org/browse/ISPN-4296
Project: Infinispan
Issue Type: Enhancement
Components: Remote Protocols
Affects Versions: 7.0.0.Alpha3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 7.0.0.Beta1
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.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)