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

Introduce incubating WebSocketEngine #5676

Merged
merged 5 commits into from Mar 5, 2024

Conversation

martinbonnin
Copy link
Contributor

@martinbonnin martinbonnin commented Mar 4, 2024

The incubating WebSocketEngine uses events instead of coroutines, making it easier to map to the underlying implementations (OkHttp, NSUrlSession and JS WebSocket are all event-based).

It also fixes a memory leak in the Apple WebSocketEngine (the NSUrlSession wasn't cancelled).

This PR also makes wasm tests "work" again. They are mostly ignored but you can now type ./gradlew build and the build will pass. They were failing previously because trying to run on a node version that did not support wasm.

Copy link

netlify bot commented Mar 4, 2024

Deploy Preview for apollo-android-docs canceled.

Name Link
🔨 Latest commit 9e05a60
🔍 Latest deploy log https://app.netlify.com/sites/apollo-android-docs/deploys/65e6e41f75d69d000807dde9

@martinbonnin martinbonnin marked this pull request as ready for review March 4, 2024 10:28
@martinbonnin martinbonnin requested a review from BoD as a code owner March 4, 2024 10:28
@martinbonnin martinbonnin changed the title Introduce incubating WebSocketEngine WebSocket branch Mar 4, 2024
@martinbonnin martinbonnin marked this pull request as draft March 4, 2024 14:29
@martinbonnin martinbonnin changed the title WebSocket branch Introduce incubating WebSocketEngine Mar 4, 2024
@martinbonnin martinbonnin marked this pull request as ready for review March 4, 2024 14:30
Copy link
Contributor

@BoD BoD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good 👍

/**
* Creates a new [WebSocket].
*
* The [WebSocket] is be garbage collected when not used anymore. Call [WebSocket.close] to close the websocket and release resources earlier.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* The [WebSocket] is be garbage collected when not used anymore. Call [WebSocket.close] to close the websocket and release resources earlier.
* The [WebSocket] will be garbage collected when not used anymore. Call [WebSocket.close] to close the websocket and release resources earlier.

Actually maybe the 1st sentence can be removed? As it's true of any type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on a crusade to remove future tense from our docs. It's what our style guide says (internal link) and I tend to agree despite being guilty of a lot of the current usage.

I'll remove the extra 'be' but I'm in favor of keeping the sentence. IO streams like InputStream usually need closing because they hold file descriptors or other resources. Here the file descriptor is released automatically on websocket error or server close. It might become the norm at some point but I don't think we're there yet.

val d = JSON.stringify(data2)
if (!disposed) {
disposed = true
listener.onError(DefaultApolloException("The JS WebSocket implementation only support text messages (got $d)"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the Buffer.isBuffer(data2) case for data messages?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 I'll update the message


import okhttp3.OkHttpClient

internal val defaultOkHttpClientBuilder: OkHttpClient.Builder by lazy {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just calling OkHttpClient.Builder() on demand?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to share the OkHttp threadpool between WebSockets and HTTP. So this is technically not used right now but I'll enable it when swapping the websocket network transport is not incubating anymore.

@martinbonnin martinbonnin merged commit 84737e9 into main Mar 5, 2024
4 checks passed
@martinbonnin martinbonnin deleted the 03-introduce-incubating-websocket-engine branch March 5, 2024 09:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants