chanwooDev opened a new issue, #6363: URL: https://github.com/apache/incubator-kie-drools/issues/6363
ticket: https://issues.redhat.com/browse/DROOLS-7648 Hi team of Drools, **Background:** When Drools compiles rules at runtime—especially when dealing with **hundreds of rules**—it uses the following construct to parallelize rule compilation: ```java rules.stream().parallel() ``` This implicitly delegates to the **ForkJoin common pool**, which is **shared across the entire JVM.** As a result, if other parts of the application also rely on the common pool for parallel or asynchronous processing, contention can occur. In our case, this shared usage **negatively impacted performance** in unrelated components due to **thread starvation** in the common pool. The issue was particularly evident during loadClass(xxx): Each rule references the same Java class in the then clause. This led to contention and **thread blocks inside the common pool** while repeatedly calling loadClass. Interestingly, I noticed this snippet in your codebase: ```java public static class ForkJoinPoolHolder { public static final ForkJoinPool COMPILER_POOL = new ForkJoinPool(); // avoid common pool } ``` This seems to acknowledge the potential risk of using the common pool—but it’s not consistently applied across the rule compilation flow. **Suggestion** To mitigate side effects and improve system isolation, I suggest explicitly using a dedicated ForkJoinPool (such as ForkJoinPoolHolder.COMPILER_POOL) during rule compilation, rather than relying on parallelStream() which uses the common pool by default. By avoiding the use of the common pool and instead utilizing a dedicated ForkJoinPool, we can **isolate the thread pool used for rule compilation**, ensuring it does **not interfere with other parts of the application**. This separation is especially critical in environments with shared JVM workloads or intensive parallel operations. If you agree with this suggestion, I would appreciate the opportunity to contribute the code changes to improve this. Thanks Chanwoo. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
