-
Notifications
You must be signed in to change notification settings - Fork 353
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
Project Loom/JDK 21 compatible #5545
Comments
That's a good point, we planned to revisit synchronized blocks all over the code. |
Will the use of ThreadLocals migrate to using some of the new scoping functionality in 21? ie ScopedValue and StructuredTaskScope? Will this lead to just a change in behaviour for Jersey's own @requestScope? |
ThreadLocals might or might not be an issue, depending on what the ThreadLocal holds. If the hold value is a subject just for a single virtual thread, it is not that an issue, afaik. But yes, the ThreadLocal use should be revisited, too. |
We have replaced the synchronized blocks for 3.1.6, along with minor ThreadLocal changes to clear the storage. However, right now we do not plan to drop the ThreadLocals as they work with virtual threads. We revisited the usage and it should not cause any harm with virtual threads. The Jersey That said, Jersey works quite well with Loom in Helidon 4 (JDK 21) already. |
@jansupol when is the 3.1.6 release happening? We (https://github.com/trinodb/trino) would love to try it out with virtual threads :) |
@wendigo The next week, likely. |
Great! Thanks @jansupol |
What would be the appropriate way to enable virtual threads when using We're currently using |
We have the |
I wonder why this issue is still open, as apparently the intended work is done in Jersey 3.1.6+ |
Sorry for the late reply, missed your comment. I confirm |
Closing as resolved |
We are preparing ourselves to upgrade to jdk 21, and was excited to see the addition of the JavaNetHttpConnectorProvider, because it would result in less dependencies to manage and automatically support virtual threads. However, after scanning the code in this repo, I see usages of synchronized methods which will result in pinned threads. Is there work under way to replace these locks with locking strategies that will not result in pinning the thread? If so, what version can I look forward to trying out that is more "project loom" friendly?
The text was updated successfully, but these errors were encountered: