[
https://issues.apache.org/jira/browse/GEODE-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131211#comment-16131211
]
Udo Kohlmeyer commented on GEODE-3411:
--------------------------------------
I'm not sure what the purpose is of this change. To confirm what I'm reading
and understanding.
Whilst monitoring my neighbor for "availability" I use HIS member-timeout to
determine if he has timed out? So the neighboring member tells me how I have to
wait for him until I can mark him as suspect.
I don't see the real benefit of now having to take the neighbors member-timeout
rather than an almost cluster defined member-timeout.
> Monitor the neighbour JVM using neihbour's member-timeout
> ---------------------------------------------------------
>
> Key: GEODE-3411
> URL: https://issues.apache.org/jira/browse/GEODE-3411
> Project: Geode
> Issue Type: Wish
> Components: membership
> Reporter: Aravind M
> Fix For: 1.3.0
>
>
> Now when a member monitor's its neighbor, It uses it's own member timeout to
> wait and then pass the suspect request to coordinator.
> But if we do so, while configuring the member timeout of all the member's, we
> are not sure for how much time that member will be removed from the view as
> it depends on the member-timeout of the jvm which is monitoring this one.
> So, if we use neighbor's member-timeout to wait for response instead of its
> own member-timeout, then we can know for how much time a member will be
> removed from the view.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
