Integrate Grizzly 5 virtual thread pool - support for virtual threads for HTTP and IIOP requests #25859
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
OndroMih
added
Component: Admin Console
OndroMih
force-pushed
the
ondromih-2025-12-virtual-threads-grizzly
branch
from
401ca7d to
454e28d
Compare
dmatej
force-pushed
the
ondromih-2025-12-virtual-threads-grizzly
branch
from
34b994f to
b74c1d4
Compare
dmatej
changed the title
dmatej
force-pushed
the
ondromih-2025-12-virtual-threads-grizzly
branch
from
4332056 to
6bcf1a3
Compare
This was referenced Jan 13, 2026
dmatej
force-pushed
the
ondromih-2025-12-virtual-threads-grizzly
branch
from
6bcf1a3 to
d14f797
Compare
Contributor
|
Here we go, so now we need to release our dependencies ... |
dmatej
force-pushed
the
ondromih-2025-12-virtual-threads-grizzly
branch
from
db42a7e to
c9c3ac5
Compare
Requires Grizzly snapshot build until Grizzly 5.0 is released. Apply virtual threads by setting the thread pool class name to "org.glassfish.grizzly.threadpool.VirtualThreadExecutorService" To do: - the "Load defaults" button in Admin Console doesn't work - it doesn't restore the default class name to use platform threads - enable virtual threads by a checkbox or allow selecting class name from a drop down from the 2 known types. Asadmin could support another argument that specifies the type of the pool instead of classname - enable to reset to defaults, either by an empty class name or by the load defaults button in Admin Console - monitoring doesn't work for the virtual threads pool License headers
Change the impl to only use a single default thread pool classname. When classname is empty or default value, then decide based on virtual argument, do not set another classname.
Based on Grizzly branch ondromih-virtualthread
Signed-off-by: David Matějček <[email protected]>
- These dependencies have to upgrade and release too, because their OSGI range blocks major changes. Signed-off-by: David Matějček <[email protected]>
…plugin Signed-off-by: David Matějček <[email protected]>
Signed-off-by: David Matějček <[email protected]>
dmatej
force-pushed
the
ondromih-2025-12-virtual-threads-grizzly
branch
from
2cdbcd9 to
db6868a
Compare
Signed-off-by: David Matějček <[email protected]>
dmatej
approved these changes
Jan 31, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This requires a new release of Grizzly 5.0, with this merged: eclipse-ee4j/glassfish-grizzly#2271
Adds support for a new "virtual" argument to thread pools - if
true, GlassFish will switch to the built-in virtual thread pool provided by Grizzly.Also allow specifying a class for the thread pool directly in the create-threadpool admin command.
Support monitoring for virtual threads.
Run monitoring test suite also for virtual threads.
EDIT, dmatej: As the Grizzly 5 is a major version, OSGI doesn't like it in combination with older dependencies which declare a version range usually
[3.0, 5.0). Therefore we need to update and release these projects too, ideally preventing it to happen again ever. Following PRs much be merged and projects released:Deployments of dependencies to Maven Central Snapshots:
Deployments of final dependencies to Maven Central
Note about OSGI ranges - Claude AI suggests incorrect solutions, while old SO is correct: https://stackoverflow.com/questions/8353771/osgi-valid-version-ranges/8354987#8354987