Skip to content

Migrate ensure_communicating transitions to new WorkerState event mechanism #5896

Closed

Description

@fjetter

The ensure_communicating transitions should be migrated to the WorkerState event mechanism as outlined in #5736 (comment)

  • The Worker._gather_dep method is broken up into
    • A method Worker._gather_remote_data which accepts an instruction indicating what keys to fetch, the remote worker address, etc. It performs the actual communication and returns a list of events about the outcome of the remote fetch (e.g. Success, DataMissing, RemoteBusy, Error, ...)
    • Handlers, e.g. Worker(State)._handle_gather_remote_busy that deal with the result of the fetch attempt
  • The ensure_communicating method is removed from the list of handle_comm every_cycle callbacks
  • The logic of ensure_communicating is moved to a private method (perspectively a method of the new class WorkerState)
  • The new private method will not perform any transitions but rather return a list of recommendations and/or instructions as necessary
  • This private method is then called as part of the transition system, e.g.
    • transition_flight_fetch
    • unpause
  • The implicit goal is to remove all invocations of self.loop.add_callback(self.gather_dep, ...) and replace this with the new callback method

Subtasks

Blocked by

Related work

Activity

  1. gjoseph92 commented on Apr 29, 2022

    @gjoseph92
    Collaborator

    Is cancellation of gather_deps in scope for this? How does that fit in? Just curious.

  2. crusaderky commented on May 1, 2022

    @crusaderky
    Collaborator

    Is cancellation of gather_deps in scope for this? How does that fit in? Just curious.

    It's out of scope.
    gather_dep will become a task that is explicitly tracked by the worker. It should be straightforward to cancel the task when that happens. Of course many other things need to happen (sender-side cancellation, ignore spurious incoming data, etc. etc.)

  3. linked a pull request that will close this issueupdate_who_has can remove workers #6342on May 20, 2022
  4. linked a pull request that will close this issuefail_hard should reraise #6399on May 20, 2022
  5. linked a pull request that will close this issueRefactor find_missing and refresh_who_has #6348on May 20, 2022
  6. linked a pull request that will close this issueRefactor busy_worker reinsertion #6379on May 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions