funky-eyes opened a new pull request, #8023:
URL: https://github.com/apache/incubator-seata/pull/8023
The transport thread-pool support needed a clearer module boundary and a
real executor abstraction: platform and virtual thread pools should be selected
centrally based on `transport.threadpool`, JDK version, and whether the loom
extension is present. This change replaces the earlier common-module workaround
with a dedicated `threadpool` layer and extends the same selection model to
scheduled executors.
- **Module split and dependency shape**
- Add `seata-threadpool` for managed thread-pool factory/provider logic
- Keep `seata-threadpool-loom` as the JDK 21+ virtual-thread SPI extension
on top of `seata-threadpool`
- Remove managed thread-pool selection code from `seata-common`
- Keep `server` defaulting to the loom module on JDK 21+, without adding
it to `seata-all` or client-side artifacts by default
- **Managed executor model**
- `ThreadPoolExecutorFactory` now lives in `seata-threadpool`
- Introduce explicit provider-backed executor types:
- `PlatformThreadPoolExecutor`
- `VirtualThreadPoolExecutor`
- `VirtualScheduledThreadPoolExecutor`
- Extend `ThreadPoolProvider` to cover both:
- regular `ThreadPoolExecutor`
- `ScheduledThreadPoolExecutor`
- **Selection rules**
- `transport.threadpool=platform` → always platform threads
- `transport.threadpool=virtual` → use loom when available on JDK 21+,
otherwise fall back to platform threads
- `transport.threadpool=auto` → use loom on JDK 25+ when present,
otherwise platform threads
- Configuration lookup now uses `ConfigurationFactory.getInstance()`
directly from `seata-threadpool` rather than reflective access from `common`
- **Virtual-thread behavior**
- For regular executors, virtual mode ignores `maximumPoolSize` and
`keepAliveTime`
- Uses `Integer.MAX_VALUE` and `SynchronousQueue` for non-cached
virtual-thread execution
- Scheduled executors now also use virtual-thread factories when the loom
provider is selected
- **Cycle avoidance**
- `seata-threadpool` depends on `seata-common` + `seata-config-core`
- `config-core` and config provider implementations keep local platform
executors (`ThreadPoolExecutor` + `NamedThreadFactory`) for their own internal
async work, avoiding a `threadpool <-> config-core` module cycle
- **Configuration and metadata**
- Add `transport.threadpool` to:
- `DefaultValues`
- `ConfigurationKeys`
- `TransportProperties`
- script/example config files for client/server/config-center
- Add BOM metadata for `seata-threadpool`
Example of the virtual executor shape introduced in the loom module:
```java
public class VirtualThreadPoolExecutor extends ThreadPoolExecutor {
public VirtualThreadPoolExecutor(
String threadPrefix, int corePoolSize, boolean daemon,
RejectedExecutionHandler rejectedHandler) {
super(
corePoolSize,
Integer.MAX_VALUE,
0L,
TimeUnit.MILLISECONDS,
new SynchronousQueue<>(),
Thread.ofVirtual().name(normalizePrefix(threadPrefix),
1).factory(),
rejectedHandler);
}
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
