Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zookeeper.apache.org
MIME-Version: 1.0
From: Andrew Purtell <apurtell@salesforce.com>
Date: Wed, 1 Mar 2017 21:37:10 -0800
Message-ID: <CAMZEaLd29LxCKAASFAKrZLRpFphAo-DgiE94a860aKVaVN8eMg@mail.gmail.com>
Subject: Partial crash bug described in Redundancy Does Not Imply Fault
 Tolerance: Analysis of Distributed Storage Reactions to Single Errors and
 Corruptions (FAST17)
To: dev@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=001a11c023c87918480549b8d4c6
archived-at: Thu, 02 Mar 2017 15:30:31 -0000

--001a11c023c87918480549b8d4c6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Is there a JIRA open for the partial crash bug described in "Redundancy
Does Not Imply Fault Tolerance: Analysis of Distributed Storage Reactions
to Single Errors and Corruptions" Aishwarya Ganesan, Ramnatthan Alagappan,
Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci-Dusseau, University of
Wisconsin=E2=80=94Madison. 15th USENIX Conference on File and Storage Techn=
ologies
(FAST =E2=80=9917)?

From
https://www.usenix.org/system/files/conference/fast17/fast17-ganesan.pdf


"Unfortunately, ZooKeeper does not recover from write errors to the
transaction head and log tail. On write errors during log initialization,
the error handling code tries to gracefully shutdown the node but kills
only the transaction processing threads; the quorum thread remains alive
(partial crash). Consequently, other nodes believe that the leader is
healthy and do not elect a new leader. However, since the leader has
partially crashed, it cannot propose any transactions, leading to an
indefinite write unavailability."


--=20
Best regards,
Andrew Purtell
apurtell@salesforce.com
apurtell@apache.org

--001a11c023c87918480549b8d4c6--