Repository navigation
feat: draining members and the index of their destinations - #62
Merged
Merged
Conversation
Signed-off-by: marcopiraccini <marco.piraccini@gmail.com>
Signed-off-by: marcopiraccini <marco.piraccini@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two additions for pods which stop gracefully, both needed by Lavoratore to move the Durable Objects of a Watt instance away before it stops.
Draining:
member.setDraining(true)sets adrainingfield in the record of the pod, which the heartbeats keep and which goes with the record when it expires or the pod deregisters.pickMemberskips draining pods, and the resolve script refuses to bind or to reassign a destination to one, atomically with the binding: a pod picked from a list read before it started draining is refused, and the registry picks another. The destinations a draining pod holds keep resolving to it.listLiveMembers()andlistPeerLoad()report the flag.Member index: with
memberIndex: trueon theRegistryand theMember, every binding also records the destination in the set of the pod,<keyPrefix>:owned:<memberId>, in the same script or transaction, and the unbinding removes it: claims, reassignments, the pruning of dead pods,addPodToDestination,deregisterDestinationand the destination methods ofMember.registry.listOwned(memberId)andmember.listOwned()read it, so that the destinations of a pod are listed without a scan. The option is off by default; the README says that every writer must maintain it and that the sets of existing destinations need a backfill.