[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-4949: -------------------------------- {quote} Therefore, we can add another layer or make the JGroups view optionally 'reliable'. {quote} I don't like your use of the word _reliable_; it suggests view installation is _unreliable_, which is not true. View installation is _reliable_, but failure detection itself is _unreliable_ and will always be. There is no way to write a reliable failure detection in an asynchronous messaging system [1]. In other words, when the failure detection _thinks_ a member has failed, a new view will be installed _reliably_ (but without consensus). {quote} I haven't considered FD, as the detection of such split would take looong anyway, I was really rather thinking of protocols where any node failure detection is constant (therefore, FD would have to suspect all other nodes when a failure is detected, and use VERIFY_SUSPECT to check who is still alive). {quote} FD_ALL or FD_ALL2 come closest to this, but they are _unreliable_ as well. {quote} Not sure if I understand; The algorithm installs the view as soon as it gets the ack or timeout from all members. {quote} I think according to the semantics implied by your use of the term _reliable view installation_, you *cannot* install a view unless you get an ack from all members in it. So in order to install view 1-50, you'd have to get an ack from members [1..50]. If a single member, e.g. 32, doesn't ack the view, you cannot install that view. In this case, I think retrying to get 50 acks until all acks have been received or a new view is to be installed would probably be best. [1] http://www.cs.yale.edu/homes/aspnes/pinewiki/FailureDetectors.html -- This message was sent by Atlassian JIRA (v6.3.8#6338)