[
https://issues.apache.org/jira/browse/CASSANDRA-20363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17930786#comment-17930786
]
Stefan Miklosovic commented on CASSANDRA-20363:
-----------------------------------------------
okay, I just moved it to a method so it does not stick out like a sore thumb.
(1) https://github.com/tommystendahl/cassandra/pull/2/files
[~tommy_s] I am really curious how your implementation would look like though.
Starting a thread and checking ... I don't know. I can imagine that can get
complicated very quickly. What if you schedule a thread after a disk is not
available and while that thread is looping, another disk would fail as well? So
you would schedule another one? What if you never make that disk available?
Then we will have threads running and there is no mechanism to stop them when
the node goes does etc ...
I just want to have something robust enough so users will not need to figure
this all out on their own.
> Add option to set a custom FSErrorHandler
> -----------------------------------------
>
> Key: CASSANDRA-20363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20363
> Project: Apache Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
> Reporter: Tommy Stendahl
> Assignee: Tommy Stendahl
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add java property to override the DefaultFSErrorHandler with a custom
> implementation.
> The use case I am looking at is a customer deployment that are using network
> disks and these can go off-line sometimes, I would like to use
> "disk_failure_policy: stop" but automatically detect when the disk is on-line
> again and just open gossip and transports so the nodes comes back UP without
> triggering a restart of the node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
