[PR] Fix executor service reload when the thread pool size provider type is not configured [shardingsphere-elasticjob]

["xubenqiang (via GitHub)" <gi...@apache.org>]

xubenqiang opened a new pull request, #2562:
URL: https://github.com/apache/shardingsphere-elasticjob/pull/2562

   Fixes #2561.
   
   Changes proposed in this pull request:
   - `ExecutorServiceReloader.reloadIfNecessary()` now resolves the configured `jobExecutorThreadPoolSizeProviderType` the same way `init()` does before comparing it with the stored type, so the default `CPU` provider no longer looks like a change on every trigger.
   - Added `ExecutorServiceReloaderDefaultTypeTest`, which builds a `JobConfiguration` without a provider type, triggers `reloadIfNecessary()` and asserts the executor instance is reused.
   
   ### Why
   
   `init()` stores the resolved type (`CPU` when nothing is configured), while `reloadIfNecessary()` compared it with the raw value (`null`). The comparison therefore never matched, so the executor was shut down and recreated on every trigger. Each new pool is wrapped by `MoreExecutors.getExitingExecutorService`, which registers a JVM shutdown hook that `shutdownNow()` does not remove, so old executors and hooks accumulated for the process lifetime (the heap histogram in the report shows ~490k instances after 4.5 days).
   
   ### Verification
   
   ```
   mvn -pl kernel -am test -Dtest=ExecutorServiceReloaderDefaultTypeTest -Dcheckstyle.skip=true -Drat.skip=true
   Tests run: 1, Failures: 0, Errors: 0
   ```
   
   With only `ExecutorServiceReloader.java` reverted, the same test fails with `Expected: is <...ListeningDecorator...>` (a different executor instance), so it pins the regression.
   
   Notes:
   - The existing `ExecutorServiceReloaderTest` could not be executed in my environment: Mockito's `MockMaker` plugin fails to initialize there for all of its tests, including unmodified ones, so I put the new case in a separate class that does not need Mockito.
   - `checkstyle`/`rat` were skipped locally for the same reason the full build is not run here; the change keeps the module's formatting conventions.
   
   ## AI assistance
   
   Prepared with an AI coding agent (DeepSeek Harness / deepseek-flash) and verified with the run above.


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Fix executor service reload when the thread pool size provider type is not configured [shardingsphere-elasticjob]

["xubenqiang (via GitHub)" <gi...@apache.org>]

xubenqiang commented on PR #2562:
URL: https://github.com/apache/shardingsphere-elasticjob/pull/2562#issuecomment-6527115229

   The Windows jobs are red on an unrelated E2E test, not on this change:
   
   ```
   [ERROR] SnapshotServiceDisableE2ETest.assertMonitorWithDumpCommand:40
           Expected java.io.IOException to be thrown, but nothing was thrown.
   ```
   
   That test asserts a connection to `DUMP_PORT - 1` fails, so it depends on nothing listening on that port on the runner; the repo has prior work on host-port collisions in tests (#2410, #2482). The JDK 17 ubuntu job only says `The operation was canceled` after the Windows failure.
   
   For context, the kernel tests pass on the failing job, including the new one:
   
   ```
   [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 -- in ...ExecutorServiceReloaderDefaultTypeTest
   [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 -- in ...ExecutorServiceReloaderTest
   ```
   
   Happy to have the jobs re-run if that is the preferred way to clear the flake.


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org