geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aravind Musigumpula <>
Subject DISCUSS : Monitor the neighbour JVM using neihbour's member-timeout (GEODE-3411)
Date Mon, 28 Aug 2017 07:20:30 GMT
Hi Team,

We have a requirement to configure  different member timeout for different members as we need
some members to survive in the view for longer time than the other the members before being
kicked out of the view in case they aren't responding.

1.       Now with the current monitoring system it is not possible to determine when the member
will be kicked out of the view if we configure different member-timeout's for some required

2.       Because if a member is not responding to any heartbeat requests, the member who is
monitoring the non-responding member will initiate check member request.

3.       In this check member request monitoring member pings the non-responding member and
waits for member-timeout of monitoring member for a response.

4.       If still there is no response, it will initiate a final suspect request to coordinator
where the coordinator does the final check waiting for coordinators member-timeout.

5.       If coordinator did not get any response, it will remove the non-responding member
from the view and publishes it.

6.       So, Here the time period for removing a member depends on its monitoring member's
and coordinator's timeout. But the monitoring member depends on the view but it may change
from time to time.

So, now when a monitoring-member doing the check on a member, if we wait for the non-responding
member's timeout instead of the monitoring member-timeout, then the time when the non-responding
member will be removed from the view depends on its own member-timeout and the coordinators
Hence we can configure different member-timeout for the required members.

I created a pull request based on the above scenario:

Is the above approach correct? Do we have any concerns around this area?
Please give your insights on this issue.

Aravind Musigumpula

This message and the information contained herein is proprietary and confidential and subject
to the Amdocs policy statement,

you may review at <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message