@Nirattay Biswas has joined the channel
#fineract 2026-01-24
Hey guys, quick question on FINERACT-1934 (thread accumulation).https://issues.apache.org/jira/browse/FINERACT-1934
I tried moving to a `ThreadPoolTaskExecutor` but it's causing context propagation issues during startup (Liquibase failures).
I thought of just adding a concurrency limit to the existing `SimpleAsyncTaskExecutor` to stop the leaks. But I'm worried that might deadlock the boot process if we have startup events waiting on each other.
Has anyone successfully capped the `ApplicationEventMulticaster` before or have suggestions on the `ThreadPoolTaskExecutor`?
I tried moving to a `ThreadPoolTaskExecutor` but it's causing context propagation issues during startup (Liquibase failures).
I thought of just adding a concurrency limit to the existing `SimpleAsyncTaskExecutor` to stop the leaks. But I'm worried that might deadlock the boot process if we have startup events waiting on each other.
Has anyone successfully capped the `ApplicationEventMulticaster` before or have suggestions on the `ThreadPoolTaskExecutor`?
I think you should get more information about the hardware, the OS, the system parameters in order to replicate the scenario.
Thanks Victor.
To clarify, I'm not really stuck on reproducing the leak—I'm mostly worried about the safety of the fix.
I actually tried swapping in `ThreadPoolTaskExecutor` and wrote a custom `TaskDecorator` to manually pass the context to the child threads. But honestly, it feels like a minefield. The context here is huge—we have to manually copy over MDC, Tenancy, Transactions, etc. If I miss even one obscure variable, we're going to end up with random, silent crashes in production.
Given how brittle that manual propagation is, do you think it's safer to just put a hard limit/cap on the current `SimpleAsyncTaskExecutor`? I'm worried the `TaskDecorator` approach is just too risky to maintain.
Or is there a standard pattern in Fineract for safely propagating full context to pooled threads that I might have missed?
To clarify, I'm not really stuck on reproducing the leak—I'm mostly worried about the safety of the fix.
I actually tried swapping in `ThreadPoolTaskExecutor` and wrote a custom `TaskDecorator` to manually pass the context to the child threads. But honestly, it feels like a minefield. The context here is huge—we have to manually copy over MDC, Tenancy, Transactions, etc. If I miss even one obscure variable, we're going to end up with random, silent crashes in production.
Given how brittle that manual propagation is, do you think it's safer to just put a hard limit/cap on the current `SimpleAsyncTaskExecutor`? I'm worried the `TaskDecorator` approach is just too risky to maintain.
Or is there a standard pattern in Fineract for safely propagating full context to pooled threads that I might have missed?
Krishna, that is a ticket from 3 years ago for Apache Fineract 1.8 now we are on 1.14, lot of things have changed since then. If you write a custom fix, it could work on your setup.
Thanks, Victor. You're right about the significant architectural changes since 1.8.
I've been testing both the custom `TaskDecorator` and the simple concurrency limit approaches locally. Unfortunately, both caused significant instability during startup (crashing Liquibase), effectively validating the compatibility warnings already documented in the source:
`// The application events (for importing) rely on the inheritable thread local security context strategy` `// This is NOT compatible with threadpools so if we use threadpools the below will need to be reworked`
Since these standard fixes are colliding with those legacy constraints and breaking the system, I'm going to hold off on a PR for now. I'll continue researching a safer approach that respects this architecture.
I've been testing both the custom `TaskDecorator` and the simple concurrency limit approaches locally. Unfortunately, both caused significant instability during startup (crashing Liquibase), effectively validating the compatibility warnings already documented in the source:
`// The application events (for importing) rely on the inheritable thread local security context strategy` `// This is NOT compatible with threadpools so if we use threadpools the below will need to be reworked`
Since these standard fixes are colliding with those legacy constraints and breaking the system, I'm going to hold off on a PR for now. I'll continue researching a safer approach that respects this architecture.
I thikn that the old ticket should be closed as non reproducible and a new ticket with the Rework/Improvement for the Apache Fineract Multi Threading model
🙌 1
also I would suggest that you should have feedback from the Jira ticket reporter 🙂
I saw you just pinged the reporter on Jira—thanks for handling that.
I completely agree with your assessment. While it was originally logged as a bug, my testing confirms that fixing it in 1.14 isn't a simple patch; it requires a fundamental redesign of the threading model to handle those context/Liquibase constraints safely.
Let's wait and see if Anjil replies. If not (or if it's stale), closing this one and opening a fresh 'Improvement/Rework' ticket to track the architectural changes properly seems like the right direction.
I completely agree with your assessment. While it was originally logged as a bug, my testing confirms that fixing it in 1.14 isn't a simple patch; it requires a fundamental redesign of the threading model to handle those context/Liquibase constraints safely.
Let's wait and see if Anjil replies. If not (or if it's stale), closing this one and opening a fresh 'Improvement/Rework' ticket to track the architectural changes properly seems like the right direction.
👍 1
I mean, you can open a new one, there is no dependency. The new Jira must have another approach and title (as previously suggested) . Because the jira reported by Anjil is for an specific issue.
Please also check the dev list history about liquibase
Understood. That makes sense—I'll treat them as separate workstreams.
I'll go ahead and open the new 'Improvement' ticket specifically for the Threading Model Rework (focusing on the context/Liquibase constraints)
And thanks for the pointer on the dev list—I'll dig through the archives to see what historical context exists regarding those Liquibase limitations.
Will proceed with that. Thanks!
I'll go ahead and open the new 'Improvement' ticket specifically for the Threading Model Rework (focusing on the context/Liquibase constraints)
And thanks for the pointer on the dev list—I'll dig through the archives to see what historical context exists regarding those Liquibase limitations.
Will proceed with that. Thanks!
Done. I've opened the new Improvement ticket here: https://issues.apache.org/jira/browse/FINERACT-2449
The limitations about liquibase is regarding the change on its license
Understood. Thanks for clarifying that it's license-related rather than a technical constraint. I'll keep that context in mind.
👍 1
Hi @Victor Romero Just wanted to give you a quick update—I’ve left a comment on the PR with what I found during reproduction.
On a related note regarding FINERACT-2449: I was doing some deep diving locally, and I actually can't get the `SimpleAsyncTaskExecutor` path to trigger, so I'm unable to validate the original 'thread accumulation' premise.
Given that, do you think it would be better to:
On a related note regarding FINERACT-2449: I was doing some deep diving locally, and I actually can't get the `SimpleAsyncTaskExecutor` path to trigger, so I'm unable to validate the original 'thread accumulation' premise.
Given that, do you think it would be better to:
- Pivot the ticket to be a proactive 'best practice' improvement (e.g., swapping the unbounded executor for a bounded one just to be safe), or
- Close it for now since we can't reproduce the leak?
@Krishna Mewara (DeathGun44) I have added links with testing cases, you can use them to test the scenarios, also you have to enable the Apache Fineract modes to make sure it is working on different conditions. I have asked in the Jira to the reporter to provide more information, if we don't receive feedback, we will close it and then instead of a Jira ticket with a bug, we can open a new ticket with the enhacement proposed and with specific use cases.
sounds perfect ,thanks victor!
Your work is valuable, just let's focuse it to the proper direction 🙂 making sure (with testing cases) that the different scenarios are covered and that we have some numbers to test concurrency.
♥️ 1