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.

Sign up for GitHub

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

Jump to bottom

Reloading a running kernel opens multiple new websockets #9133

Closed
karlaspuldaro opened this issue Oct 2, 2020 · 9 comments · Fixed by #9189
Closed

Reloading a running kernel opens multiple new websockets #9133

karlaspuldaro opened this issue Oct 2, 2020 · 9 comments · Fixed by #9189
Labels
status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Milestone
3.0

Comments

@karlaspuldaro
Copy link
Contributor

karlaspuldaro commented Oct 2, 2020 •
edited

Description

Reloading the page with a notebook running a long process starts a websocket explosion. A new websocket is opened every few seconds with a pending status 101.
The number only stops increasing when the program stops and kernel goes idle, or when the kernel is manually interrupted.

image

Related to #9010

Reproduce

  1. Create a new notebook
  2. Execute the following code:
import asyncio
i = 0
while i < 60:
    print(i)
    await asyncio.sleep(1)
    i = i+1
  1. While code is executing refresh the page
  2. While the kernel is busy still finishing the previous execution,(you can check the notebook server logs or inspect we WS tab in the browser developer tool), a new websocket is created at about every 10secs
  3. After the kernel finishes its execution, it goes into idle state and the new websockets are no longer created

Expected behavior

Similar to what happens in the classic notebook, only one websocket should be open per open notebook.

Context

  • Operating System and version: MacOS Version 10.14.6
  • Browser and version: Chrome Version 85.0.4183.121
  • JupyterLab version: JupyterLab v3.0.0b8
Command Line Output 
```
[D 2020-10-02 18:50:20.867 ServerApp] Initializing websocket connection /api/kernels/14328a37-0316-4787-b4b5-39397a9314b0/channels
[D 2020-10-02 18:50:20.869 ServerApp] 101 GET /api/kernels/14328a37-0316-4787-b4b5-39397a9314b0/channels?session_id=c30c3e66-0b50-4356-8fab-f476fd0099a3 (127.0.0.1) 1.79ms
[D 2020-10-02 18:50:20.869 ServerApp] Opening websocket /api/kernels/14328a37-0316-4787-b4b5-39397a9314b0/channels
[D 2020-10-02 18:50:20.869 ServerApp] Getting buffer for 14328a37-0316-4787-b4b5-39397a9314b0
[D 2020-10-02 18:50:20.869 ServerApp] Connecting to: tcp://127.0.0.1:57087
[D 2020-10-02 18:50:20.869 ServerApp] Connecting to: tcp://127.0.0.1:57091
[D 2020-10-02 18:50:20.870 ServerApp] Connecting to: tcp://127.0.0.1:57088
[D 2020-10-02 18:50:20.870 ServerApp] Connecting to: tcp://127.0.0.1:57089
[D 2020-10-02 18:50:21.203 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:21.210 ServerApp] Accepting token-authenticated connection from 127.0.0.1
[D 2020-10-02 18:50:21.214 ServerApp] 200 GET /api/contents/?content=1&1601679021207 (127.0.0.1) 4.13ms
[D 2020-10-02 18:50:22.207 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:23.205 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:24.209 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:25.206 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:26.211 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:27.212 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:28.219 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:28.575 ServerApp] Accepting token-authenticated connection from 127.0.0.1
[D 2020-10-02 18:50:28.576 ServerApp] 200 GET /api/kernels?1601679028571 (127.0.0.1) 1.18ms
[D 2020-10-02 18:50:28.577 ServerApp] Accepting token-authenticated connection from 127.0.0.1
[D 2020-10-02 18:50:28.577 ServerApp] 200 GET /api/terminals?1601679028573 (127.0.0.1) 0.87ms
[D 2020-10-02 18:50:29.219 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:30.225 ServerApp] activity on 14328a37-0316-4787-b4b5-39397a9314b0: stream
[D 2020-10-02 18:50:30.875 ServerApp] Accepting token-authenticated connection from 127.0.0.1
[D 2020-10-02 18:50:30.876 ServerApp] 200 GET /api/sessions?1601679030871 (127.0.0.1) 1.26ms
[D 2020-10-02 18:50:30.880 ServerApp] Initializing websocket connection /api/kernels/14328a37-0316-4787-b4b5-39397a9314b0/channels
[D 2020-10-02 18:50:30.882 ServerApp] 101 GET /api/kernels/14328a37-0316-4787-b4b5-39397a9314b0/channels?session_id=149e7a3b-51e3-4f2c-beb8-f2d529e88631 (127.0.0.1) 1.79ms
[D 2020-10-02 18:50:30.882 ServerApp] Opening websocket /api/kernels/14328a37-0316-4787-b4b5-39397a9314b0/channels
[D 2020-10-02 18:50:30.882 ServerApp] Getting buffer for 14328a37-0316-4787-b4b5-39397a9314b0
[D 2020-10-02 18:50:30.882 ServerApp] Connecting to: tcp://127.0.0.1:57087
[D 2020-10-02 18:50:30.883 ServerApp] Connecting to: tcp://127.0.0.1:57091
[D 2020-10-02 18:50:30.883 ServerApp] Connecting to: tcp://127.0.0.1:57088
[D 2020-10-02 18:50:30.883 ServerApp] Connecting to: tcp://127.0.0.1:57089
```
@jasongrout
Copy link
Contributor

jasongrout commented Oct 2, 2020 •
edited

Is it easy for you to check with jlab version 3.0.0rc4?

@jasongrout jasongrout added this to the 3.0 milestone Oct 2, 2020
@karlaspuldaro karlaspuldaro mentioned this issue Oct 2, 2020
Merged
@karlaspuldaro
Copy link
Contributor Author

@jasongrout I was also able to reproduce the bug on 3.0.0rc4

@jtpio
Copy link
Member

jtpio commented Oct 9, 2020 •
edited

This sounds similar to: #7560 (linking for xref)

jasongrout added a commit to jasongrout/jupyterlab that referenced this issue Oct 20, 2020
@jasongrout
Only check session attributes we care about when determining if we ne…
edd04f7 
…ed to update.

This was accidentally comparing extra information the server gives us, and in particular the last activity time was *always* forcing an update. Instead, we just check relevant attributes to determine if we need to update.

Fixes jupyterlab#9133
@jasongrout jasongrout mentioned this issue Oct 20, 2020
Merged
@jasongrout
Copy link
Contributor

@karlaspuldaro - is this a problem with 2.x as well? We're trying to decide if we need to backport the change in #9189 to 2.2.9.

@jasongrout
Copy link
Contributor

Yes, I just checked and it is a problem in 2.2.x as well, so it would be good to backport #9189.

@jasongrout
Copy link
Contributor

CC @ajbozarth @marthacryan

@ajbozarth
Copy link
Contributor

Given we're targeting the release for tomorrow is #9189 ready to merge?

@jasongrout
Copy link
Contributor

I think it is. I think it's been ready to go for several days now :).

@jasongrout
Copy link
Contributor

but I'm biased :)...just trying to find someone to review it...

I'm happy to walk through the code with you if you want to review it.

@github-actions github-actions bot added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Apr 21, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Milestone
3.0
Development

Successfully merging a pull request may close this issue.

Update session and kernel manager data only if there was a real change. jasongrout/jupyterlab
4 participants
@jasongrout @jtpio @ajbozarth @karlaspuldaro