On 10/30/2013 08:46 PM, Mircea Markus wrote: > On Oct 30, 2013, at 7:28 PM, William Burns <mudokon...@gmail.com> wrote: > >> Since it seems I can't comment on the wiki itself, I am just replying here. >> >> I wonder if the third option 'Primary partition' is desirable. I >> think availability in some cases would be harmed more than we would >> like. >> >> Lets say you have a 5 node cluster where 3 of the nodes are behind the >> same router and the remaining 2 are behind a different one. If the >> router crashes, power loss etc. for the 3 and are no longer >> addressable you have your 2 partitions (possibly 1 or even 4). When >> this occurs the other 2 nodes would go into read only mode since they >> lost the quorum check. > agreed. > >> But the 3 nodes that are "writable" can't be >> accessed any longer and thus no writes can be performed on the >> cluster. It seems we would still want to allow writes to provide as >> high of availability as possible. > we actually don't take the decision for the user but to plug in his own > PartitionHandlingStrategy to make a wiser decision based on their network > specifics. > The quorum approach written there is just a suggestion, I'll make that > clearer. > >> Also if we did have read only, what criteria would cause those nodes >> to be writeable again? > Changing the availability status is possible through JMX, so either manual > intervention or some MergeListeners that do that automatically.
You should probably outline the MergeListeners on wiki as well. I believe that automatic merge is highly desirable, because for example long GC may cause partition more likely than network failure - and you don't want to require some monkey pushing JMX after every long GC. Radim > >> There is no guarantee when the other nodes >> will ever come back up or if there will ever be additional ones >> anytime soon. >> >> - Will >>> [1] >>> https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions > Cheers, -- Radim Vansa <rva...@redhat.com> JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
