tkobayas commented on issue #7187: URL: https://github.com/apache/incubator-kie/issues/7187#issuecomment-6188429434
> `drools-model-codegen` BaseModelTest creats KieContainer with UUID based ReleaseId, so ksessions are piled up...? No. KieContainer is not retained unless created by `newKieContainer(containerId, ...)` (ReleaseId is not relevant), so Kiecontainer, KieBase and KieSession are GC'ed. Same for ksession creation in `drools-test-coverage`. Possible ksession leak scenarios are: 1. **Long-lived container or KieBase**: `getKieClasspathContainer()`, `newKieContainer(containerId, ...)` (cached in `KieServicesImpl`), or a KieBase held in a static / `@BeforeAll` field. Every undisposed session accumulates in `kbase.statefulSessions` for the life of the JVM (surefire fork). Incremental updates (`addPackages`, etc.) also keep updating those stale sessions. 2. **Realtime clock + a timer that is actually scheduled** (`timer`, `@expires`, etc.): `JDKTimerService` owns a `ScheduledThreadPoolExecutor`. Its core thread is non-daemon and never times out. Only `dispose()` calls `shutdownNow()`. Without it the thread leaks, and pending jobs keep the session reachable. Pseudo-clock tests are not affected. 3. **MBeans enabled**: `DroolsManagementAgent` (static) keeps the session registered until `dispose()`. They are very rare cases, so it wouldn't cause OutOfMemory even if they pile up. ## Conclusion We don't need to dispose ksession in unit tests. We may ignore Copilot suggestions about it. -- 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]
