Daniel Kec

Couldn't reproduce on Ryzen-based Linux

Workaround is possible with setting up request context manually ```java @Inject private Provider requestContextControllerFactory; @Incoming("fromKafka") @Acknowledgment(Acknowledgment.Strategy.MANUAL) @Asynchronous public CompletionStage getMessage(KafkaMessage message) { final var requestContextController = requestContextControllerFactory.get(); requestContextController.activate(); try {...

Fix is not suitable for backporting to the Helidon 1.x which is already EOL. For anyone experiencing this issue with Helidon 1.x please consider upgrade or workaround with streaming output...

We are not going to support any kind of implicit request scope in reactive messaging as any kind of thread bound context can be realized in reactive stream pipeline

Helidon 3.x uses maven-jar-plugin `3.0.2`, Helidon 4.x `3.3.0`, support for module main class [MJAR-238](https://issues.apache.org/jira/browse/MJAR-238) was added in `3.1.1`. Unfortunately main class is derived from manifest configuration, discussed here by @ljnelson...

Also soon to be the only correct way of monitoring pinned virtual threads

Workaround: ```java WebServer server = builder .config(config.get("server")) .routing(r -> r.any("/", (req, res) -> res.send("ok"))) .putSocket("admin", s -> s.from(builder.sockets().get("admin")).routing(r -> r .any((req, res) -> res.send("admin ok")))) .build() .start(); ```

And it will be cool!

We have already prepared JEP-209 troubleshooting section for serialization filter doc as part of WLS integration documentation: 

Fix didn't make it to 4.x https://github.com/helidon-io/helidon/blob/be27e3007b59f39531ed0c2e48aee4178141b525/integrations/db/ojdbc/src/main/resources/META-INF/helidon/serial-config.properties#L17