-
Notifications
You must be signed in to change notification settings - Fork 2.1k
WebSockets: handle onClosing #2574
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
WebSockets: handle onClosing #2574
Conversation
|
|
|
Welcome @stevenschlansker! |
ede316c to
17b4e97
Compare
17b4e97 to
01b6dad
Compare
|
This looks good to me, looking at the parent code (https://github.com/square/okhttp/blob/ee1ba4656d80ed62485387217271c7fa31dc888e/okhttp/src/jvmMain/kotlin/okhttp3/WebSocketListener.kt#L20) that call to |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: brendandburns, stevenschlansker The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
fwiw, you shouldn't expect PortForward to run forever. It's very much intended for transient, debug/development scenarios, not persistent connections. If you want a persistent connection you should expose your application as a Service. |
|
Agreed. Thank you! |
We are trying to use the
PortForwardclass to communicate with our kubernetes pods for testing purposes. We've been having trouble with tunneled connections timing out or receiving unexpected EOFs. There is little documentation about how this api server proxy works, which makes diagnosing any problems a struggle.I added voluminous debug logs and discovered that the server seems to be sending an
onClosingevent with a code of 1000, indicating that it will not communicate with us further in this session.I don't understand why the api server proxy is closing our session which we intend to use further. But, if it does, it does no good to keep it open clientside: you will wait as long as you like but the server won't send any more data.
Shutting down the client side in this case seems to allow the higher levels to re-establish the connection and continue. We still have some stability problems with the PortForward, but this seems to make it significantly better.