[ 
https://issues.apache.org/jira/browse/IGNITE-7648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452217#comment-16452217
 ] 

Ilya Kasnacheev commented on IGNITE-7648:
-----------------------------------------

[~ascherbakov] since your commit doesn't really removes 
IGNITE_ENABLE_FORCIBLE_NODE_KILL system property, can you please reword this 
ticket's title and description? Otherwise it's confusing currently.

I think it's a reasonable change, but:
What happens if user still fails to set failure detection timeout? Maybe we 
should have a default value?
How does it address the following scenario: There's a node that can't open 
communication to any other node, and so it happens that it will drop all other 
nodes from topology, because it will report via discovery that its peers are 
malfunctioning and not the node itself? I think that was the main reasoning 
behind the whole ENABLE_FORCIBLE_NODE_KILL business.

> Revert IGNITE_ENABLE_FORCIBLE_NODE_KILL system property.
> --------------------------------------------------------
>
>                 Key: IGNITE-7648
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7648
>             Project: Ignite
>          Issue Type: Improvement
>    Affects Versions: 2.3
>            Reporter: Alexei Scherbakov
>            Assignee: Alexei Scherbakov
>            Priority: Major
>             Fix For: 2.6
>
>
> IGNITE_ENABLE_FORCIBLE_NODE_KILL system property was introduced in 
> IGNITE-5718 as a way to prevent unnecessary node drops in case of short 
> network problems.
> I suppose it's wrong decision to fix it in such way.
> We had faced some issues in our production due to lack of automatic kicking 
> of ill-behaving nodes (on example, hanging due to long GC pauses) until we 
> realised the necessity of changing default behavior via property.
> Right solution is to kick nodes only if failure threshold is reached. Such 
> behavior should be always enabled.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to