]
Mario Fusco commented on DROOLS-1313:
-------------------------------------
There are 2 distinct things to be considered here:
1. Will this work?
Also looking at what it does internally, yes I believe your approach is ok (for now, see
2.).
2. Is this supported?
Every time you use an internal class (not belonging to public kie api) you are doing
something that by definition is not supported. We don't give any guarantee that those
internal classes will remain as they are now and their behaviour can change literally at
any new commit.
I hope this helps,
Mario
Memory Leak - but is this a supported scenario for Dynamic rule
management
--------------------------------------------------------------------------
Key: DROOLS-1313
URL:
https://issues.jboss.org/browse/DROOLS-1313
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Bill Tuminaro
Assignee: Mario Fusco
Attachments: heap.png, SAVE_SimpleTest.java, SAVE_SimpleTest2.java,
SAVE_SimpleTest4.java, SAVE_SimpleTest5.java, SimpleTest2_dump1.PNG,
SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG,
SimpleTestDump3.PNG, simpleTestThirdDump4.png
I have a reproducer that shows a clear memory leak based on heap dumps created and
reviewing them with the Eclipse Memory Analyzer tool (
http://www.eclipse.org/mat/).
However, I am not sure this is a supported scenario. If this is a supported approach
this needs to get fixed, otherwise we need to use another approach.
The attached source does this:
+*Initialize stuff*+
- Create a new ReleaseId
- Create a new KieFileSystem
- Generate and write the PomXML for the ReleaseId created above
- Create a new KieModuleModel
- Create a new KieBaseModel
- Write the ModuleModel XML to the KieFileSystem
- Write 2 rules into the KieFileSystem
+*1st build and dump*+
- Create a new KieBuilder
- Do a buildall() with the KieBuilder
- Create a new KieContainer
- Create a new KieSession from the KieContainer
- Print out the rules in the KieContainer for the package used in my rules
- Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can
see we have 2 classloaders for each class created for these rules. This is not the leak,
yet, just curious if this is expected.
+*2nd build and dump*+
- Delete 2 rules from the KieFileSystem created above
- Call incrementalBuild() on the KieBuilder created above
- Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID
created above
- Add 2 new rules to the KieFileSystem created above
- Call incrementalBuild() on the KieBuilder created above
- Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID
created above
- Print out the rules in the KieContainer for the package used in my rules
- Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
- Rule_120_Triggered_Part_1_ 0 is not there
- Another class loader and instances of
Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
+*3rd build and dump*+
- Delete 1 rule from the KieFileSystem created above
- Call incrementalBuild() on the KieBuilder created above
- Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID
created above
- Add 2 new rules to the KieFileSystem created above
- Call incrementalBuild() on the KieBuilder created above
- Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID
created above
- Print out the rules in the KieContainer for the package used in my rules
- Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
- Rule_120_Triggered_Part_1_ 0 is STILL not there
- TWO more class loaders and instances of
Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
- Another class loader and instances of
Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part
of the leak)