[
https://issues.apache.org/jira/browse/GEODE-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravind M updated GEODE-3411:
-----------------------------
Description:
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.
was:
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.
> 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
>
> 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
(v6.4.14#64029)
