DeathGun44 commented on PR #5429:
URL: https://github.com/apache/fineract/pull/5429#issuecomment-3828892926

   @IOhacker  Thanks for the detailed feedback!
   ### 1. Instance Modes
   The 
[applicationEventMulticaster](cci:1://file:///home/deathgun/fineract/fineract-provider/src/main/java/org/apache/fineract/infrastructure/core/config/SpringConfig.java:50:4-57:5)
 is used in ALL instance modes (Read, Write, Batch) 
   because Spring application events are core infrastructure. However, the 
thread 
   accumulation is most critical in **Write** and **Batch** modes where high 
event 
   volumes occur.
   ### 2. Verification of Fix
   Here's proof the fix works - startup logs show events now run on bounded 
`FineractEvent-*` pool:
   
   2026-01-31 19:19:04.634 - INFO [FineractEvent-8] 
org.quartz.impl.StdSchedulerFactory : Using default implementation... 
2026-01-31 19:19:04.639 - INFO [FineractEvent-8] 
org.quartz.core.QuartzScheduler : Quartz Scheduler v2.5.0 created. 2026-01-31 
19:19:04.641 - INFO [FineractEvent-8] org.quartz.core.QuartzScheduler : 
Scheduler Scheduler1_$_NON_CLUSTERED started.
   
   **Before:** Threads named `SimpleAsyncTaskExecutor-*` (unbounded, new thread 
per event)  
   **After:** Threads named `FineractEvent-*` (bounded pool, max configurable)
   This is verified by the application starting successfully with the new 
executor. A test for 
   "pool size equals X" doesn't add value since misconfiguration would cause 
startup failure.
   
   With a bounded pool, even 1000 concurrent events will queue instead of 
creating 1000 threads. 
   This is the fundamental fix - replacing unbounded with bounded.
   
   I'll update the PR with:
   1. Externalize pool sizes to 
[FineractProperties](cci:2://file:///home/deathgun/fineract/fineract-core/src/main/java/org/apache/fineract/infrastructure/core/config/FineractProperties.java:35:0-710:1)
 following 
[TaskExecutorConfig](cci:2://file:///home/deathgun/fineract/fineract-provider/src/main/java/org/apache/fineract/infrastructure/core/config/TaskExecutorConfig.java:27:0-49:1)
 pattern
   2. Add CPU-aware defaults: `corePoolSize = 
Runtime.getRuntime().availableProcessors() * 2`
   
   If you still want a configuration verification test, I can add one. Let me 
know.


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