[
https://issues.apache.org/jira/browse/GEODE-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16328369#comment-16328369
]
ASF GitHub Bot commented on GEODE-3411:
---------------------------------------
aravindmusigumpula commented on issue #1075: GEODE-3411 Do Final check based on
suspected member-timeout
URL: https://github.com/apache/geode/pull/1075#issuecomment-358216404
@bschuchardt @kohlmu-pivotal @metatype
Consider a Geode cluster in which some nodes contain a particular type of
data which is critical to the business and hosts a large amount of data. Some
nodes may host data which is not critical to the business and hosts less amount
of data compared to the previous type of nodes.
If both the type of nodes are going through some operation which is making
them unresponsive, the former type of node may take a couple of seconds extra
than the later to respond.
In this scenario is it fair to give the same member-timeout to all the
members?
What if we want to wait for a little longer time for such nodes.
In the present configuration in geode, we cannot wait a little longer for
some nodes when compared to do this although we can configure different
member-timeout for all the nodes. But i think no one will ever configure
different timeouts for each node because those member-timeouts will be used to
monitor their neighbors.
In this solution, we all do is wait for the suspected member-timeout instead
of its own timeout during final check.
It has no backward implications also, if some one wants to use the existing
behavior they will continue to use the same member-timeouts for all the nodes.
So the behavior of the system is preserved.
If you have any concerns in this solution, please let me know.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Do Final check based on suspected member-timeout.
> -------------------------------------------------
>
> Key: GEODE-3411
> URL: https://issues.apache.org/jira/browse/GEODE-3411
> Project: Geode
> Issue Type: Wish
> Components: membership
> Reporter: Aravind M
> Priority: Major
> Labels: pull-request-available
>
> The idea is able to make critical member to survive in the view for a little
> longer time than others.
> But we cannot do with the current suspect mechanism.
> Now a member can be removed from the view in two cases: one is missing
> heartbeat and second is missing acknowledgement of message.
> In the first case ,the final check is done by coordinators member-timeout and
> in the second case the final check done by suspecting member by its own
> timeout.
> So, in these two cases if we manage to suspect the member by the
> member-timeout of the suspected one in the final check then we can achieve to
> make a member survive in the view a little longer by configuring a greater
> member-timeout to that member.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
