As we start to introduce the ability for Liberty components exposing Virtual Thread capabilities, the need to restrict this functionality has been requested.
Policy changes to the Executor Policy under https://github.com/OpenLiberty/open-liberty/issues/27054 are making way for JakartaEE11 Concurrency api's that allow VT's.
A global policy class com.ibm.wsspi.threading.ThreadPolicy can be used to override any related VT behavior within Liberty.
By default we will return true, an embedder could provide an implementation in the service registry
that would return false and would override any configurable virtual thread config setting – warning
message issued if override of config encountered – An error will occur if more than one service of this
type is registered
public boolean enableVirtualThreads();
• Applies Globally to any Liberty config/API’s involving virtual threads (Including concurrent-3.1)
• This will not prevent or log direct Java API creation and usage of Virtual Threads
As we start to introduce the ability for Liberty components exposing Virtual Thread capabilities, the need to restrict this functionality has been requested.
Policy changes to the Executor Policy under https://github.com/OpenLiberty/open-liberty/issues/27054 are making way for JakartaEE11 Concurrency api's that allow VT's. A global policy class com.ibm.wsspi.threading.ThreadPolicy can be used to override any related VT behavior within Liberty.
By default we will return true, an embedder could provide an implementation in the service registry that would return false and would override any configurable virtual thread config setting – warning message issued if override of config encountered – An error will occur if more than one service of this type is registered public boolean enableVirtualThreads();
• Applies Globally to any Liberty config/API’s involving virtual threads (Including concurrent-3.1) • This will not prevent or log direct Java API creation and usage of Virtual Threads