Hello Nuwagaba Victor , Unfortunately, this can happen with legacy cumulative loans in high-volume tenant environments.
The affected periodic/accrual/penalty jobs do not use distributed Spring Batch execution for those loan types. Instead, they may load all affected loans and related entities into the same persistence context and attempt to process them in one run. With large datasets, EclipseLink can then retain a very large number of managed entities and change-tracking records until flush/commit, which can eventually exhaust the JVM heap. Increasing the heap may delay the failure, but it usually does not solve the root cause if the job still processes too many loans/entities in a single transaction or persistence context. The recommended direction is: Prefer progressive loan products where possible (Migration path) Progressive loans have better support for batch-oriented/distributed job execution. This allows the workload to be split and processed more safely instead of accumulating all affected loan state in memory at once. Consider job-level improvements if customization is possible (Optimization of the job itself) A more robust implementation would process loans in smaller chunks, flush and clear the persistence context periodically, and avoid holding all affected entities in memory for the full job execution. However, this would require code changes and careful validation because loan accrual and penalty processing is financially sensitive. So, in summary: this is a known type of limitation with the legacy cumulative loan processing approach. Where possible, moving to progressive loans is the better long-term option because it opens the possibility of distributed Spring Batch execution and avoids this class of memory pressure during large scheduled job runs. Kind regards, Adam > On Jun 1, 2026, at 10:18 AM, nuwagaba victor <[email protected]> > wrote: > > Hello @[email protected], > I hope you are doing well. > I am reaching out to request guidance regarding a critical issue I am facing > with Apache Fineract periodic and penalty jobs in a Dockerized multi-tenant > environment. > We are experiencing a recurring failure during scheduled job execution, > specifically during Quartz jobs handling loan accruals and penalty processing. > Error Details: > The job fails with the following exception: > <image.png> > Environment Context: > Deployment: Dockerized Apache Fineract instance > Database: MySQL (InnoDB) > Issue occurs during periodic and penalty job execution for specific tenants > JVM heap size has already been increased, but the issue persists > Initial Investigation: > At first, we suspected a resource limitation issue (heap size), and > accordingly increased memory allocation for the container and JVM. However, > the problem continues to occur. > From the stack trace, it appears that EclipseLink is consuming excessive > memory while tracking entity changes in the persistence context during batch > processing, eventually leading to heap exhaustion during flush operations. > Request for Guidance: > Could you kindly advise on the following: > Whether this is a known issue with large batch processing in Fineract’s > periodic/penalty jobs > Recommended best practices for processing large loan datasets without > exhausting JVM heap > Whether job execution should be modified to support batching or periodic > persistence context clearing > Any configuration tuning recommendations for EclipseLink, Quartz, or > transaction handling in high-volume environments > Suggested architectural patterns for safely handling accrual and penalty > processing in large tenant datasets > We would greatly appreciate any insights or recommended approaches to > stabilize job execution under production-scale workloads. > Thank you very much for your time and support. > > Kind Regards > Nuwagaba Victor
