Simple solution: each node works on power-via-ethernet: when the cable is unplugged, it's down.
Then we think of a redundant design at the physical network level to make it unlikely. Sanne On 24 April 2013 16:38, Manik Surtani <[email protected]> wrote: > > On 24 Apr 2013, at 16:08, Mircea Markus <[email protected]> wrote: > >> >> On 22 Apr 2013, at 17:43, Manik Surtani wrote: >> >>> On 22 Apr 2013, at 14:47, Bela Ban <[email protected]> wrote: >>> >>>> >>>> >>>> On 4/19/13 11:51 AM, Sanne Grinovero wrote: >>>>> TBH I'm not understanding which problem this thread is about :) >>>>> >>>>> Surely network partitions are a problem, but there are many forms of >>>>> "partition", and many different opinions of what an "acceptable" >>>>> behaviour is that the grid should implement, which largely depend on >>>>> assumptions the client application is making. >>>> >>>> >>>> This thread is not about providing different application data merge >>>> policies, which is also something that needs to be done, but more likely >>>> in the context of eventual consistency in Infinispan. This thread is >>>> about a *primary partition* approach which says that only members in a >>>> primary partition are allowed to make progress, and others aren't. >>>> >>>> 'No progress' needs to be defined, but so far I think we've agreed on a >>>> notion of read-only members, which do provide access to data, but don't >>>> allow modifications. One could also think about not even allowing reads >>>> as the data might be stale. Perhaps this is configurable. >>> >>> +1 >>> >>>> The idea is that if only a primary partition can make progress, and only >>>> *one* primary partitions exists in the system at any time, then we can >>>> simply overwrite the data of minority partitions with data from the >>>> primary partition on a merge. >>>> >>>> So a primary partition approach is not about how to merge (possibly >>>> conflicting) data after a cluster split heals, but about how to >>>> *prevent* conflicting data in the first place. >>>> >>>> If you think about this in CAP terminology, we sacrifice availability in >>>> favor of consistency. >>> >>> Precisely. This would still follow the strongly consistent model. >> I don't think consistency is preserved in at least the following situations: >> - the read-only partition has more than numOwner members. Reads in the >> active partition would miss data. Also the conditional operation, that rely >> on existing data, perform incorrectly. > > Good point. > >> - data is deleted in the active partition but copies are kept in the >> read-only partition. >> The 2nd problem can be solved with tombstones. The first problem cannot be >> solved and we can only target an eventual consistent cluster. That should be >> made very clear to the users. >> >> >> Cheers, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org) >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > [email protected] > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
