[
https://issues.jboss.org/browse/ISPN-5159?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-5159:
------------------------------------
[~rvansa] I wasn't thinking about requiring changes to the JGroups configuration
either, my thinking was that the default configuration should be good enough to avoid
merges during startup.
I don't think all the internal caches can be recreated on the fly: e.g. the cluster
registry cache is created by core and then used by other components like query, we'd
need both a way to notify the cluster registry to rebuild the cache, and a way for the
cluster registry to tell all the components that they need to rebuild their slice of the
cluster registry cache (assuming that those components do have the necessary
information).
Make concurrent startup smooth
------------------------------
Key: ISPN-5159
URL:
https://issues.jboss.org/browse/ISPN-5159
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 7.1.0.Beta1
Reporter: Radim Vansa
Assignee: Dan Berindei
When starting many instances in parallel, it often happens that the node does not detect
its neighborhood very well and this results in many subclusters, merging views etc.
Merging two available partitions has undefined results (AFAIK). While we can expect that
there are no requests to the cluster from the application ^1^, Infinispan itself uses some
caches to store internal information (HotRod routing, Protobuf etc...). It would be better
if the available-available merge would provide hooks for rebuilding this info.
^1^) Being able to start the cluster with reads/writes disabled and enable them only when
the cache has expected number of members would be convenient, too.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)