> On Dec 11, 2023, at 11:27 AM, Raymond Huffman
> wrote:
>
> On our fork of Cassandra, we've implemented some custom behavior for handling
> CommitLog and SSTable Corruption errors. Specifically, if a node detects one
> of those errors, we want the node to stop itself, and if the node is
> re
Hello Raymond,
Do you have draft changes to look at?
I'd suggest a more general approach, as some interfaces seem to
overlap each other. There is the FSErrorHandler, and the
JVMStabilityInspector both of which are currently not configurable via
user configuration. I think it would be possible to
Adding a poison-pill error option on finding of corrupt data makes sense to me.
Not sure if there's enough demand / other customization being done in this
space to justify the user customizable aspect; any immediate other approaches
come to mind? If not, this isn't an area of the code that's cha
I can see this as a strong improvement in Cassandra management and support
it.
+1 non binding
On Mon, Dec 11, 2023 at 8:28 PM Raymond Huffman
wrote:
> Hello All,
>
> On our fork of Cassandra, we've implemented some custom behavior for
> handling CommitLog and SSTable Corruption errors. Specific
Hello All,
On our fork of Cassandra, we've implemented some custom behavior for
handling CommitLog and SSTable Corruption errors. Specifically, if a node
detects one of those errors, we want the node to stop itself, and if the
node is restarted, we want initialization to fail. This is useful in
Ku
