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

Support CIO server for wasm-js and js #4466

Open
wants to merge 29 commits into
base: 3.1.0-eap
Choose a base branch
from

Conversation

whyoleg
Copy link
Contributor

@whyoleg whyoleg commented Nov 8, 2024

Subsystem
Server CIO

Motivation
Probably fixes https://youtrack.jetbrains.com/issue/KTOR-865/Add-node.js-server-engine, though not sure, may be more specific issue should be created

Solution
Most of the code in ktor-server-cio is just copied with minor changes.

P.S. This is the last PR in a series of ktor server support for wasm-js and js! wasm-wasi will be next, probably, if I will be able to find working runtime which supports preview1 socket APIs...

@osipxd osipxd self-requested a review November 8, 2024 17:41
@osipxd
Copy link
Member

osipxd commented Nov 13, 2024

Relates to:

  • KTOR-2939 ApplicationEngine.start()/stop() should be suspending
  • KTOR-7459 Implement a suspending version of EmbeddedServer.start(wait=true)

Copy link
Member

@osipxd osipxd left a comment

Choose a reason for hiding this comment

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

This is the last PR in a series of ktor server support for wasm-js and js!

Thank you, it's a huge work 🎉

Please, check JVM builds on CI, they fail after two hours with timeout because of hanging NettyHttp2ServerCommonTest.

@@ -179,6 +179,8 @@ public abstract class BaseApplicationResponse(
}
} catch (closed: ClosedWriteChannelException) {
throw ChannelWriteException(exception = closed)
} finally {
flushAndClose()
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need to call flushAndClose inside .use { } block?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

TBH, I'm not fully sure if this fixes the original issue (some tests failure), so I will revert this change...
The idea behind this change is that use on ByteWriteChannel is custom and uses close which in reality calls flushAndClose, but doesn't wait for it completion.
so use{} and flushAndClose are mostly the same, except for the fact that flushAndClose really suspends

Copy link
Contributor Author

Choose a reason for hiding this comment

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

reverted in 9bbd0d3

Now JVM tests are working fine, looks like this was the reason, as this is the only change which affects JVM.
But now testErrorInBodyClosesConnection started to fail again - it shows it as flaky, so may be it's really related to this fireAndForget close method in channels

Copy link
Member

@osipxd osipxd Nov 14, 2024

Choose a reason for hiding this comment

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

@e5l, could you take a look? Should we call flushAndClose instead of deprecated close inside of use?

Copy link
Member

Choose a reason for hiding this comment

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

The difference is in the exception: flushAndClose can throw if the flush is failed. Could you check if this is the case?

Copy link
Contributor Author

@whyoleg whyoleg Nov 22, 2024

Choose a reason for hiding this comment

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

Do you think may be it will be better to create a separate issue for this to investigate? :)

I see, that the same test fails sometimes (flaky) not only for js/wasm-js. And as I reverted this change, it should not affect anything.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, let's move this investigation into a separate task

@whyoleg whyoleg force-pushed the commonize-cio-server branch from c94816f to b0029a1 Compare November 13, 2024 18:05
@whyoleg
Copy link
Contributor Author

whyoleg commented Nov 13, 2024

@osipxd should I create an additional issue for this, or https://youtrack.jetbrains.com/issue/KTOR-865/Add-node.js-server-engine will be fine?

Relates to:

  • KTOR-2939 ApplicationEngine.start()/stop() should be suspending
  • KTOR-7459 Implement a suspending version of EmbeddedServer.start(wait=true)

Do you think it will be better to extract those changes and create a separate PR for them? If so, I will do it :)

@osipxd
Copy link
Member

osipxd commented Nov 14, 2024

Should I create an additional issue for this, or https://youtrack.jetbrains.com/issue/KTOR-865/Add-node.js-server-engine will be fine?

@e5l, was this task created for some new Node.js engine or CIO fits the purpose?

Relates to:

  • KTOR-2939 ApplicationEngine.start()/stop() should be suspending
  • KTOR-7459 Implement a suspending version of EmbeddedServer.start(wait=true)

Do you think it will be better to extract those changes and create a separate PR for them? If so, I will do it :)

Yes, it would be great to discuss this separately. Probably we should deprecate the existing start/stop implementation and at some point and gradually migrate to the suspend version.

@whyoleg
Copy link
Contributor Author

whyoleg commented Nov 14, 2024

Yes, it would be great to discuss this separately.

Extracted to #4481

@e5l
Copy link
Member

e5l commented Nov 20, 2024

I think we can adjust the issue to include wasm

@whyoleg
Copy link
Contributor Author

whyoleg commented Nov 22, 2024

Hey @osipxd I've rebased PR on latest changes (e.g EmbeddedServer.startSuspend). Do you think there is something else needed from me here?

I saw, that there is some progress to improve tests stability, but those changes are only in main currently. Are you planning to merge them into 3.1.0-eap anytime soon?

@whyoleg whyoleg requested a review from osipxd November 22, 2024 09:02
Copy link
Member

@osipxd osipxd left a comment

Choose a reason for hiding this comment

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

Thank you! LGTM

As we decided to move investigation of the flaky test to a separate task, it would be great to ignore this test. However, I don't think it is possible to ignore a test only on one platform. I thought about adding annotations like @JsIgnore, @JvmIgnore, etc., but it feels out of the task scope. I think we'll merge tests stabilizing changes today, so we'll check if it helps.

@e5l e5l force-pushed the 3.1.0-eap branch 2 times, most recently from d0ced88 to 1cc5abf Compare November 26, 2024 11:55
@osipxd
Copy link
Member

osipxd commented Nov 26, 2024

Hey @whyoleg, we've merged commits fixing tests flakiness to 3.1.0-eap branch. Could you rebase this PR one more time?

@whyoleg whyoleg force-pushed the commonize-cio-server branch from d96a40b to 339695c Compare November 26, 2024 17:40
@whyoleg
Copy link
Contributor Author

whyoleg commented Nov 26, 2024

Sure, @osipxd, rebased!

@whyoleg
Copy link
Contributor Author

whyoleg commented Nov 26, 2024

@osipxd: TC builds failed because of Canceled by Osip Fatkullin: Wrong agent requirements - is it something expected ? :)

@osipxd
Copy link
Member

osipxd commented Nov 26, 2024

is it something expected ? :)

Yes, it was because of me broken CI exactly at that moment. Should be fixed now. Restarted the build chain

@whyoleg
Copy link
Contributor Author

whyoleg commented Nov 27, 2024

Okay, I've checked a bit and I see that testErrorInBodyClosesConnection and testErrorInBodyClosesConnectionWithContentLength are now failing only on js because of timeout (from mocha). They are not failing on wasmJs target, because there is no such global timeout and so the request in this test fails after 30 seconds httpclient timeout - which is not what really tested in this test, so we can say that it's not really passes on wasmjs either.
Same timeout exists in native implementation, but locally it's not triggered and tests finishes in less than a second

TBH, I don't fully understand how I can investigate this failure... If you do have any idea, I would like to hear it!

* Use stdlib `use` extension-function
* Update type checks
@whyoleg whyoleg force-pushed the commonize-cio-server branch from 32bd03e to 693399c Compare November 29, 2024 18:03
@@ -34,7 +34,7 @@ fun Project.configureJs() {
internal fun KotlinJsSubTargetDsl.useMochaForTests() {
testTask {
useMocha {
timeout = "10000"
timeout = "60000"
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've increased timeout for JS tests here, as I have no idea from where the issue in JS engine comming :)

For some reason, the behavior in Js/WasmJs differs here - I can't understand if it's the issue in ktor-network implementation or in some expect-actual, or in some other thing...

@whyoleg whyoleg requested review from osipxd and e5l November 29, 2024 18:05
Copy link
Member

@e5l e5l left a comment

Choose a reason for hiding this comment

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

lgtm, but we need to merge 2.1.0 update first

@e5l e5l force-pushed the 3.1.0-eap branch 2 times, most recently from 95e95b0 to 1971db7 Compare December 3, 2024 14:07
@osipxd
Copy link
Member

osipxd commented Dec 4, 2024

Kotlin 2.1.0 update is tracked here:

@osipxd osipxd force-pushed the 3.1.0-eap branch 6 times, most recently from d50a66e to cc3f8f8 Compare December 12, 2024 10:34
@osipxd osipxd force-pushed the 3.1.0-eap branch 2 times, most recently from 7c22c8a to f555d1a Compare December 19, 2024 10:14
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.

9 participants