Remove Executor Config

[SentryMan]

This lib is only meant to be used with virtual threads, what need is there to customize the executor?

[rbygrave]

what need is there to customize the executor?

For running performance comparison testing between Virtual Threads and Platform threads?
To provide some custom Executor that might have a maximum limit or some other interesting feature?

I know Helidon SE had effectively their own executor to provide nice fast graceful shutdown - graceful shutdown that doesn't rely on AtomicLong counters for active requests (I designed the first cut of that).

I'd be loathed to remove this just yet [with the native synchronise fix in 23, not yet in a LTS version / 25]

[SentryMan]

For running performance comparison testing between Virtual Threads and Platform threads?

Some features in this server (like sse) have been designed with the assumption of virtual threads. We also have no async support, so I believe it to be a bit unwise to use platform threads.

To provide some custom Executor that might have a maximum limit or some other interesting feature?

If someone needs it, we can re-add it. As is though, I think it's a potential landmine.

[with the native synchronise fix in 23]

The fix is in JDK 24, but I don't see what that has to do with anything, it's not like they'll backport it to 21. I've spent the last month upgrading my job's CI/CD to work with JDK 24 so I'm unbothered.

In any case, without async you'll end up blocking a platform thread no matter if you use VT/PT with synchronized.

[rbygrave]

ok, let merge it.

[robaho]

Often times depending on work load a pool of platform threads will outperform virtual threads. Yes, they may all be consumed and so latency can go up if the server is saturated but modern OS easily handle 10k threads. Which is often enough for many systems - especially if special use.

[SentryMan]

Well alright then

[robaho]

I had a version of robaho httpserver that used a platform executor and passed off a runnable to handle the connection once some data was available to read. It was surprisingly efficient, but as I said, it often depends on the workload.

The bigger reason I would suggest leaving it is that people might be in a monitoring executor - gathered stats, etc - it would be a transparent way of doing this.

But, I don't know the api profile here - was simply pointing out an alternative view.

[SentryMan]

simply pointing out an alternative view.

A very convincing alternative view