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 Loom #8007

Closed
sbordet opened this issue May 16, 2022 · 2 comments · Fixed by #8465
Closed

Support Loom #8007

sbordet opened this issue May 16, 2022 · 2 comments · Fixed by #8465
Assignees

Comments

@sbordet
Copy link
Contributor

sbordet commented May 16, 2022

Target Jetty version(s)
10.0.x

Enhancement Description
With project Loom being integrated in Java 19+22, we should offer an option to call Handlers with a virtual thread.
This would allow testing by early adopters.

sbordet added a commit that referenced this issue May 22, 2022
Implemented virtual threads support for HTTP/1.1, HTTP/2 and HTTP/3.

Signed-off-by: Simone Bordet <[email protected]>
@sbordet sbordet linked a pull request May 22, 2022 that will close this issue
sbordet added a commit that referenced this issue May 23, 2022
Updates after review.

Signed-off-by: Simone Bordet <[email protected]>
sbordet added a commit that referenced this issue Jul 31, 2022
Alternative implementation of support for virtual threads for HTTP/1.1, HTTP/2 and HTTP/3.

The virtual thread support is in AdaptiveExecutionStrategy.
When virtual threads are supported and enabled, reserved threads are disabled and
blocking tasks are run in a virtual thread instead that being executed by the Executor.

Signed-off-by: Simone Bordet <[email protected]>
@AlanBateman
Copy link

AlanBateman commented Aug 14, 2022

Just a quick comment to say that testing if the Thread.startVirtualThread method is present will help detect if the runtime is 19+, using Runtime.version().feature() >= 19 would be simpler. Also just to say that this method throws UOE if not running with --enable-preview.

One thing you might want to consider is creating an ExecutorService with Executors.newVirtualThreadExecutor rather than using the Thread API directly. I understand the change here is more of "hand off" rather than a deep change but once advantage of using an ES is that it will mean the virtual threads are tracked and it means they will show up in thread dumps and serviceability tools. At this time, virtual threads that are created directly with the Thread API aren't visible to serviceability tools because they aren't party of any "grouping".

@sbordet
Copy link
Contributor Author

sbordet commented Aug 14, 2022

@AlanBateman thanks for the suggestions! We'll make the changes.

@sbordet sbordet reopened this Aug 14, 2022
@sbordet sbordet self-assigned this Aug 14, 2022
sbordet added a commit that referenced this issue Aug 15, 2022
Now using Executors.newVirtualThreadPerTaskExecutor() to execute
tasks, so the executor is tracked by the runtime for thread dumps, etc.

Signed-off-by: Simone Bordet <[email protected]>
@sbordet sbordet linked a pull request Aug 15, 2022 that will close this issue
sbordet added a commit that referenced this issue Aug 15, 2022
Now using Executors.newVirtualThreadPerTaskExecutor() to execute
tasks, so the executor is tracked by the runtime for thread dumps, etc.

Signed-off-by: Simone Bordet <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants