Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get notify on server event #466

Open
fcollonval opened this issue Apr 3, 2021 · 5 comments
Open

Get notify on server event #466

fcollonval opened this issue Apr 3, 2021 · 5 comments

Comments

@fcollonval
Copy link
Member

Problem

The initial question on Gitter was:

A server extension running long actions (mamba-org/gator#132) can delay shutting down the server. Is there a way to be notified the server wants to shutdown?

But there may be other events worth notifying.

Proposed Solution

I would suggest callback registration like the on implemented for widget events: https://ipywidgets.readthedocs.io/en/latest/examples/Widget%20Events.html

Additional context

@blink1073
Copy link
Contributor

Thanks for raising the issue!

@echarles
Copy link
Member

echarles commented Apr 3, 2021

just curious, what "network channel" are you thinking to for such events: an existing/new websocket channel, or comm channel...?

@fcollonval
Copy link
Member Author

just curious, what "network channel" are you thinking to for such events: an existing/new websocket channel, or comm channel...?

Actually in the reported case, I only need the main server to notify the server extension. So there is no need for communication with the frontend or the kernels.

@vidartf
Copy link
Member

vidartf commented Apr 8, 2021

So we discussed this in today's dev meeting, and noted that it would be nice to add a generic event framework for things like this. That would allow events including kernelspec added/modified, file modified, kernel started/stopped - really any REST call other than GET. We could also add file system polling for contents events.

Such a framework should be able to emit both in-process on the server side, and to the client side (ideally with events defined by JSON schemas). It was noted that this sounded very similar to some of the work that is going on in the telemetry effort (#364, https://github.com/jupyter/telemetry), so in order to avoid having two parallel event frameworks it would be beneficial to share as much as possible.

A proposed solution was to merge the in-process emitter logic from the telemetry effort, and use this as a "private" event framework for now. Alternatively, we could create a trait on ServerApp that is the "status", and could be observed using trailets observer, where "shutting down" could be one such status.

@vidartf

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants