ISPN-263 Handle cluster partitions

https://issues.jboss.org/browse/ISPN-263

I added one more commit with some test fixes.
From the way this is documented that isn't what we would do.   You are
talking about a different scheme that allows for majority to recover.  And
realistically could only work for if less than numOwners left since you
could lose data temporarily.
On Aug 8, 2014 12:55 PM, "Dan Berindei" <notifications@github.com> wrote:

> In
> documentation/src/main/asciidoc/user_guide/chapter-32-Clustering_modes.adoc:
>
> > +bank account information). On the other hand, if Infinispan is used as an best-effort
> > +cache, e.g. to cache web pages in a proxy, the partitions are perfectly tolerable.
> > +
> > +The following sections describes the way Infinispan handles split brains and
> > +successive failures when partition handling is enabled, followed by a section on
> > +configuring the partition handling functionality.
> > +
> > +==== Split brain
> > +
> > +We assume a partition happens when *numOwners* or more nodes disappear at the
> > +same time. When this happen two (or more) partitions form which are not aware of
> > +each other. Each such partition does not start a rebalance, but enters in degraded mode:
> > +
> > +- request (read and writes) for entries that have all the copies on nodes within
> > +this partition are honoured
> > +- requests for entries that are partially or totally owned by nodes that disappeared
>
> Let's say we have a cluster with 4 nodes, numOwners = 2, and there is a 3
> to 1 split.
> The node that is by itself should enter degraded mode, but the others
> should rebalance stay in available mode. If the 1-node partition would
> allow reads, the user could see stale entries.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/infinispan/infinispan/pull/2785/files#r16003368>.
>