+1 on thinking about Java 25 for 3.0.0 rather than just bumping to 21.
The reason it is worth it now is the pinning fix: JEP 491 ("Synchronize Virtual
Threads without Pinning"), delivered in Java 24 and carried into the 25 LTS.
Before that, in 21 to 23, a virtual thread that blocked on I/O inside a
synchronized block stayed pinned to its carrier thread, and under load that
could exhaust the carrier pool and stall progress. That is a real concern for
us, because we have a fair amount of synchronized code sitting in exactly the
I/O bound paths where you would want to use VTs. On 24/25 the VT unmounts and
frees the carrier while it waits, so we would not have to go and rewrite every
synchronized block as ReentrantLock first, which is the migration a lot of
libraries had to do (MySQL Connector/J, Resilience4j and others). Native/JNI is
the one remaining pinning case, but that is narrow.
Where this could actually matter in Storm: the places that spend their time
waiting rather than computing are the obvious candidates. Netty/transport
worker connections, external lookups in bolts (DB, HTTP, cache), and the
various ack/metrics/heartbeat paths that talk to ZooKeeper/Nimbus. These are
classic thread-per-connection or bounded-pool setups today, and a
thread-per-task VT model could simplify them and scale better when a topology
fans out to a lot of blocking calls
.
What we would want to be careful about: the hot path is the executor's
disruptor queues and the spout/bolt processing loop, and a lot of that is CPU
bound message passing, not blocking I/O, so VTs do not help there and should
not be forced in. This is about targeted use in the I/O bound corners, not
running everything on virtual threads. We would also want to watch ThreadLocal
usage, since Scoped Values (finalised in 25) are the intended replacement and
we lean on thread locals in a few spots.
So my argument is: if we are doing a new major anyway, baselining 3.0.0 on Java
25 rather than 21 costs us little extra now and saves a second baseline bump
later. It also keeps the door open to actually explore VTs in the blocking
paths.
Realistically it will be a good while before we are in a position to do a Storm
4, so 3.x is where any of this experimentation has to live regardless, and I
would rather not start that line on a baseline we already know we will want to
move off.
I am not saying we commit to adopting VTs in 3.0.0 itself. Just that 25 as the
baseline is the enabler, and we can prototype on a branch from there.
Gruß
Richard
On 2026/06/24 13:24:26 Rui Abreu wrote:
> Julien, master is being compiled with JDK 21, but our test pipelines
> run both 21 and 25.
>
> On Wed, 24 Jun 2026 at 10:49, Julien Nioche
> <[email protected]> wrote:
> >
> > Hi Rui,
> >
> > Are we moving to Java 25 in 3.x?
> >
> > Thanks
> >
> > Julien
> >
> >
> >
> > On Mon, 22 Jun 2026 at 14:57, Rui Abreu <[email protected]> wrote:
> >
> > > Hey folks,
> > >
> > > We have several good contributions in master and a few more undergoing
> > > PRs.
> > > I'm keen on releasing 3.0.0 to the community soon. I don't mind at all
> > > doing the release.
> > >
> > > Let me know what you think
> > >
> > > On Wed, 20 May 2026 at 19:02, Rui Abreu <[email protected]> wrote:
> > > >
> > > > Totally agree. I would say we should keep merging dependabot PRs into
> > > > 2.x for some months, but only do a release if we have reports of a
> > > > bug, like the one we patched in 2.8.8.
> > > > Otherwise, 3.0.0 will be the way to go to better utilise our manpower
> > > resources.
> > > >
> > > > On Wed, 20 May 2026 at 18:38, Richard Zowalla <[email protected]> wrote:
> > > > >
> > > > > Given our current man power it might be beneficial, if we decide on a
> > > > > EOL strategy for the 2.x release line before going into 3.x (dropped
> > > > > clojure, Java 21 baseline), so we have a clear way on how long we want
> > > > > to support the 2.x branch with releases.
> > > > >
> > > > > Given our slow pace in getting the required votes, we might have an
> > > > > issue with maintaing to release lines in parallel over a longer period
> > > > > of time. Think we can do that for a few months but not endlessly.
> > > > >
> > > > > Might be worth a discussion thread on the dev@ list. wdyt?
> > > > >
> > > > > Am Mittwoch, dem 20.05.2026 um 16:44 +0100 schrieb Rui Abreu:
> > > > > > Hello @Richard Zowalla
> > > > > >
> > > > > > We can consider releasing 3.0.0 over the next week or so.
> > > > > >
> > > > > > On Sun, 10 May 2026 at 23:09, Rui Abreu <[email protected]> wrote:
> > > > > > >
> > > > > > > Thanks for the PRs @Richard Zowalla , much appreciated.
> > > > > > > I have merged them and dealt with the subsequent dependabot
> > > > > > > avalanche.
> > > > > > > Apologies if you received a whole bunch of Jenkins errors.
> > > > > > > I was using AI + GH client to deal with the dependabot PRs in
> > > > > > > batches
> > > > > > > and it was being quite helpful, right up until the point and it
> > > > > > > decided to merge a few PRs whose tests were still ongoing
> > > > > > >
> > > > > > > problematic Merges
> > > > > > > * #8632 (Jersey 4.0.2 upgrade on 2.x)
> > > > > > > * #8615 (Checkstyle 13.4.2 on master)
> > > > > > >
> > > > > > > Both have been reverted and both master and 2.x are ok.
> > > > > > >
> > > > > > > I'll create a RC for 2.8.8 during the week.
> > > > > > >
> > > > > > > On Sun, 10 May 2026 at 17:01, Rui Abreu <[email protected]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Ok, we can hold off on 3.0.0 for now.
> > > > > > > > I'll focus on making sure 2.8.8 has the necessary changeset and
> > > > > > > > then we can get the RC going.
> > > > > > > >
> > > > > > > > On Sun, May 10, 2026, 16:58 Richard Zowalla <[email protected]
> > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > 2.8.8 is fine for me. Guess we need to confirmed dependabot
> > > > > > > > > for
> > > > > > > > > 2.x branches too (+ license update action)
> > > > > > > > >
> > > > > > > > > 3.0.0 would need the Java 21 bump before (as discussed in the
> > > > > > > > > related discussion - dont know if there are other things like
> > > > > > > > > the Jitter RFC stuff for it) - perhaps there is something
> > > > > > > > > else.
> > > > > > > > >
> > > > > > > > > Gruß
> > > > > > > > > Richard
> > > > > > > > >
> > > > > > > > > > Am 10.05.2026 um 17:13 schrieb Rui Abreu <[email protected]
> > > >:
> > > > > > > > > >
> > > > > > > > > > Hi folks,
> > > > > > > > > >
> > > > > > > > > > Just trying to understand if you are keen on performing a
> > > > > > > > > > release for both
> > > > > > > > > > versions shortly
> > > > >
> > >
> >
> >
> > --
> > *Julien Nioche *
> >
> >
> > digitalpebble.com <http://www.digitalpebble.com/>
>