Re: [jakartaee-platform-dev] about Virtual Threads in Jakarta EE 11

[Romain Manni-Bucau <rmannibucau@xxxxxxxxx>]

Hi,

I guess the main impact for EE is to ensure all specs using threads (servlet, batch, concurreny even if this one is pretty much useless in practise, ...) enable or not the usage of virtual threads (as the EJB was not allowing custom threads for ex) to explicitly it support it.

It can surely be done globally in a shared spec (ee concurrency can be a location but the platform umbrella can be a better one too).

In terms of vendor support it means supporting a configurable and injectable virtual thread factory preconfigured for the EE env and to not rely on the default virtual thread scheduler (virtual threads being just more or less runnable in a thread pool at the end as we have today, just lower level integrated).

It can mean making forbidden or undefined the usage of Thread.startVirtualThread(Runnable) (which uses the default thread pool so a global forkjoin pool which is incompatible with multplie classloader until the app server rewrites the code to make it friendly - tccl handling, context handling etc).

So overall I think it either means enabling the standalone (flat classpath and no EE classloader) case - but this means defining it in EE even if most app server have this mode, this does not exist in the spec and/or defining an app server mode to enable users to use it in a way which is EE stack friendly.

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

Le dim. 12 févr. 2023 à 18:44, reza_rahman@xxxxxxxxx <reza_rahman@xxxxxxxxx> a écrit :

I suspect most of the impact is really in the implementation layer rather than the API layer. This is mostly because traditionally Jakarta EE has abstracted multi-threading anyway.

The most concrete end result may be that we rethink priorities in terms of adding more reactive/non-blocking/NIO APIs into the platform. That said, one area of exploration is whether there is a need to have a managed version of virtual threads. I suspect since they are not as heavyweight, using them directly in Jakarta EE applications is fine.

I am curious too what vendor innovations/analysis may happen though.

---

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of ma zhen <mz1999@xxxxxxxxx>
Sent: Sunday, February 12, 2023 12:04 AM
To: jakartaee-platform-dev@xxxxxxxxxxx <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [jakartaee-platform-dev] about Virtual Threads in Jakarta EE 11

 

Hi all,

I watched the video of the Jakarta EE Monthly Platform Architecture Call on February 7th. https://www.youtube.com/watch?v=UD1ecWJMljY

According to my understanding, current application servers use the NIO framework to handle network requests, for example, glassfish uses grizzly. When Virtual Threads is introduced, it will have a big impact on the implementation architecture of existing application servers. Glassfish will abandon grizzly and re-implement it with a blocking API.

It seems that this meeting did not discuss how Jakarta EE 11 will use Virtual Threads. I would like to know what the working group thinks about it. Thanks!

Best regards,

mazhen

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev