Damans227 opened a new pull request, #13565:
URL: https://github.com/apache/cloudstack/pull/13565

   ### Description
   
   The AsyncJobManager's API and Worker executor thread pool sizes are 
currently derived solely from `db.cloud.maxActive` (`maxActive/2` and 
`maxActive*2/3` respectively). This coupling doesn't account for environments 
with predominantly I/O-bound workers, where threads are held waiting on 
external responses for extended periods and higher pool sizes may be needed 
independently of the DB connection count.
   
   This PR adds two global config keys:
   - `api.job.pool.size` (default: 50)
   - `work.job.pool.size` (default: 50)
   
   The actual pool size is `Math.max(configured value, db-derived default)`, 
preserving existing behavior by default while allowing operators to increase 
pool sizes when workloads require it. Pool sizes and their derivation are 
logged at startup for observability.
   
   ### Types of changes
   
   - [ ] Breaking change (fix or feature that would cause existing 
functionality to change)
   - [ ] New feature (non-breaking change which adds functionality)
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [x] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   - [ ] Build/CI
   - [ ] Test (unit or integration test code)
   
   ### Feature/Enhancement Scale or Bug Severity
   
   #### Feature/Enhancement Scale
   
   - [ ] Major
   - [x] Minor
   
   ### How Has This Been Tested?
   
   Added unit tests in `AsyncJobManagerImplTest` that call `configure()` 
directly and assert on the real core pool size of the created executors (via 
reflection), covering both the "configured value wins" and "db-derived default 
wins" cases for both pools. Ran the full `AsyncJobManagerImplTest` suite 
locally (7 tests), all passing.
   
   #### How did you try to break this feature and the system with this change?
   
   Verified the new config keys follow the existing `ConfigKey` pattern in this 
class (category, type, name, default, description, isDynamic, scope), and that 
`isDynamic` is correctly set to `false` since the executor pools are only 
created once at startup, so a dynamic config change wouldn't take effect 
without a restart anyway.


-- 
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]

Reply via email to