[
https://issues.jboss.org/browse/ISPN-4296?page=com.atlassian.jira.plugin....
]
Gustavo Fernandes commented on ISPN-4296:
-----------------------------------------
The limitation is restored successful only for REPL caches, as shown in
[{{ClientAsymmetricClusterTest}}|https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/test/java/org/infinispan/client/hotrod/ClientAsymmetricClusterTest.java]
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|https://github.com/infinispan/infinispan/blob/master/server/hot...]
Was this intentional? Shouldn't DIST behaves the same way as REPL?
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.Alpha5, 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.3.15#6346)