Add Poll class, fix some tests, throttle polling.

[afshin]

Fixes #3929

• Adds a Poll class to @jupyterlab/coreutils to abstract polling and exponentially backing off in case of failure.
• Adds Poll class tests.
• Cleans up doc strings in the running extension.
• Updates different ad hoc polls to use the Poll class:
  • @jupyterlab/services:KernelManager#models
  • @jupyterlab/services:KernelManager#specs
  • @jupyterlab/services:SessionManager#models
  • @jupyterlab/services:SessionManager#specs
  • @jupyterlab/services:TerminalManager#models
  • @jupyterlab/statusbar:MemoryUsage#metrics
• Switches kernel manager and session manager to async.
• A future enhancement of the Poll class that is possible is adding Poll[Symbol.asyncIterator], Poll#return(), and Poll#next() methods to make the poll an async iterator.
• Updates tests and switches some previously asynchronous tests to synchronous (as long as the semantics are not modified).
• Re-enables dialog tests in dialog.spec.tsx file that were accidentally disabled and modernizes them to jest API.
• Cleans up Dialog class API and adds an instance tracker: Dialog.tracker

State diagram of the possible state transitions between poll phases

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[afshin]

The broken tests are correct. I will remove the [WIP] tag when ready for review.

[jasongrout]

@afshin - I notice this is still WIP. Do you want me to review it yet for the prerelease this week?

[afshin]

@jasongrout Sorry! I put it back into WIP because some things needed refactoring. This will be ready before our meeting tomorrow. Is that enough time for you to review?

[afshin]

@jasongrout Assuming tests pass, this is ready for review. I created an issue to refactor the file browser model, which is the only poll I left out, because it is more deeply embedded in the file browser and it will not require an API change so we can do it later.

[jasongrout]

Thanks. I'm looking at this now.

[jasongrout]

I have a PR to submit to this PR with some slight (but I feel important) modifications to the math of the jitter algorithm. I also looked a bit into jitter algorithms. https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/ was one of the few interesting results I found in a quick search, and discussed more at https://trac.torproject.org/projects/tor/ticket/23816#no2. Using the terminology from the blog post, we essentially have a variant of their "Equal Jitter" approach. Perhaps it would be better to use something like "Decorrelated Jitter", which essentially puts a static lower bound on the polling interval, but just increases the max exponentially, and picks a uniform random value between the min and max. I like this approach because it tends to really spread clients out quickly, rather than still grouping them around the exponential values. What do you think about using that algorithm instead? Then "no jitter" would just be basically a setTimeout with a single value.

[afshin]

That sounds good to me, the decorrelated jitter sounds like a good behavior to me. Please post a PR if you're working on one. If not, I can implement it tomorrow.

[afshin]

Also, one change I recently made that I want to undo is that instead of await this.ready; I think it should do:

if (!this.isReady) {
  await this.ready;
}

or something like that. I'm not sure whether to add Poll#isReady or simply check for this.state.phase === 'instantiated'. But the point is to avoid an additional frame request happening every single time a client calls one of the public methods.

[jasongrout]

I'm not sure whether to add Poll#isReady or simply check for this.state.phase === 'instantiated'.

I've been puzzling through the state transitions for a while this afternoon. I think checking the state phase won't work because the phase could be any number of things after the initialization. I like the synchronous .isReady and have used that elsewhere.

[afshin]

Any phase after instantiated can be arbitrarily interrupted without causing a break in the promise chain since its tick will be resolved with the new tick interrupting it (or if unnecessary for a new started or refreshed tick, it'll simply ignore). The only uninterruptible phase is instantiated, so the implementation of isReady would look like:

get isReady(): boolean {
  return this.state.phase !== 'instantiated';
}

Because any other phase can

[afshin]

In reality, instantiated could be interrupted too without breaking the chain, it's just that it would break the contract of what the when promise actually means, so it needs to respected by checking for it in the public methods.

[afshin]

Hm, I think we should talk about jitter, I'm a little unsure about what we want.

[jasongrout]

I opened https://github.com/afshin/jupyterlab/pull/24 for some changes to the kernel manager logic. I'm continuing to work my way through the files in the PR, and I may add more to that PR.

[jasongrout]

Can you elaborate on why you took out the else here?

[afshin]

This was causing reconnects (after stopping the server and starting again) to fail. I didn't definitively understand why but it seems reasonable if we have both the cookie and the header to use both and it turned out to eliminate a class of failures after reconnect.

[jasongrout]

One more PR with changes to the terminal manager: https://github.com/afshin/jupyterlab/pull/25

[jasongrout]

For a future PR, I noticed in using the API it might be nice if .refresh() returns the .tick promise, so you can just do await poll.refresh() instead of await poll.refresh(); await poll.tick().

[jasongrout]

Note to self: this may need to be changed back to false after my recent manager updates.

[jasongrout]

Note to self: this may need to be changed back to false after my recent manager updates.

[afshin]

For a future PR, I noticed in using the API it might be nice if .refresh() returns the .tick promise, so you can just do await poll.refresh() instead of await poll.refresh(); await poll.tick().

We could potentially do something like:

async refresh(passthrough = false): Promise<void> {
  if (this.isDisposed) {
    return;
  }

  if (this.state.phase === 'constructed') {
    await this.ready;
  }

  if (this.state.phase !== 'refreshed') {
    this.schedule({
      interval: Private.IMMEDIATE,
      payload: null,
      phase: 'refreshed',
      timestamp: new Date().getTime()
    });
  }

  if (passthrough) {
    await this.tick;
  }
}

But I'm not sure. The idea was to keep the API super simple and predictable: you always get the tick you created, the refreshed tick. But it is a little counter-intuitive if all you care about is the result of the refresh roundtrip to a server and not just the instruction to refresh.

[jasongrout]

But I'm not sure.

I'm not sure either. I'm happy to leave it as-is, with a simple consistent api, and see if that's okay, or if we want to make it slightly more convenient later.

[afshin]

The spot you flagged did indeed fail.

Feel free to push directly into afshin:api-requests branch if you want, because I won't be able to merge a PR until tomorrow otherwise.

[afshin]

I apparently neglected to git push the doc string commit on my other machine, so I added it now.

[jasongrout]

And the tests all pass! Thanks again for all your work on this one, @afshin!

[ian-r-rose]

Nice!