Session and Kernel object are cloned upon server-side changes #6142
Update : I found that #3669 is related to what I've posted here and somewhat resolves it, but the 2nd case (
Describe the bug
First case1. SessionManager refreshes running sessions by fetching session models from the server. If these new models are different from the models it currently has it will update its models and then signal this fact to listeners. The ServiceManager (a listener) will pick up this signal and will in turn attempt to connect to the new session model. The connectTo methods of session and kernel objects will clone the session and its kernel.
2. SessionManager calls `this._refreshRunning()` every ten seconds. This calls DefaultSession's `listRunning()` which calls `updateRunningSessions()`.
First case1. When the SessionManager fetches session models from the server (via `_refreshRunning()` which is called every ten seconds) and notices that this data is different from its current session models, it emits a signal (`this._runningChanged.emit(models)`).
When the ServiceManager (
If a newly fetched session model's ID matches the ID of an existing session model, `update()` will be called on the existing session model.
The result is that the original kernel object (which is redundant now) will not be disposed of and remain in memory. Furthermore, the original kernel’s web socket will not be closed. This is a bug, but does not seem to noticeably affect performance.
When could this occur?
The same thing will occur in the second case, every time a session's model is changed server-side.
Desktop (please complete the following information):
If available, please include the following details:
$PATH: /Users/raja.shravan/miniconda3/envs/second_3.7.2-env/bin /Users/raja.shravan/miniconda3/envs/second_3.7.2-env/bin /Users/raja.shravan/miniconda3/bin /Users/raja.shravan/.pyenv/shims /Library/Frameworks/Python.framework/Versions/3.5/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin
Command Line Output
The text was updated successfully, but these errors were encountered:
Fixes jupyterlab#6142 Before, a kernel was handed to the session, so it was confusing who was responsible for disposing the kernel connection. Now the API is changed so that the DefaultSession creates the kernel connection, so it is responsible for disposing it.