You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed, while working on a plugin that required to extend the ReadinessCheck, that this check is implemented not through plugins but hardcoded as an RPC method during initialization.
It would be much cleaner if these checks can be implemented as plugins, as in the future if someone needs to do something similar, it would be easier and faster to do it.
LivenessCheck is a trivial probe to check if process is UP or DOWN
ReadinessCheck requires 2 checks:
Make sure that the sync is within a certain distance from the head of the chain. For this, a numMaxBlocksBehind parameter is used to check for distance. This check could be done in the plugin version by registering an BesuEvent for addSyncStatusListener(SyncStatusListener).
Using a parameter minPeers check that the number of peers connected is higher than that value. In the plugin version, I can't see a way to have access to the number of peers but this could easily be exposed by P2PService.
Acceptance Criteria
Readinees and Liveness checks are re-implemented without side effects. Both probes will be functioning the same as before but now implemented as plugins.
The text was updated successfully, but these errors were encountered:
Should this be implemented inside the plugins directory, with a new sub-directory called health-checks, or can they go inside the existing rocksdb directory?
Description
I noticed, while working on a plugin that required to extend the ReadinessCheck, that this check is implemented not through plugins but hardcoded as an RPC method during initialization.
It would be much cleaner if these checks can be implemented as plugins, as in the future if someone needs to do something similar, it would be easier and faster to do it.
numMaxBlocksBehind
parameter is used to check for distance. This check could be done in the plugin version by registering anBesuEvent
foraddSyncStatusListener(SyncStatusListener)
.minPeers
check that the number of peers connected is higher than that value. In the plugin version, I can't see a way to have access to the number of peers but this could easily be exposed byP2PService
.Acceptance Criteria
Readinees and Liveness checks are re-implemented without side effects. Both probes will be functioning the same as before but now implemented as plugins.
The text was updated successfully, but these errors were encountered: