[jboss-jira] [JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management

[Mario Fusco (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13305368#comment-13305368 ] 

Mario Fusco commented on DROOLS-1313:
-------------------------------------

I changed your last reproducer adding a for loop to deploy the last 2 releases 10 times each and taking a heap dump at the end of this process as it follows 

{code}
    public static void main(String[] args) {
        System.out.println("current working dir is: " + System.getProperty("user.dir"));
        SAVE_SimpleTest4 st = new SAVE_SimpleTest4();
        st.initializeKfs();
        st.firstBuildOfRulesAndContainer();
        for (int i = 0; i < 10; i++) {
            st.secondBuildOfRulesAndContainer();
            st.thirdBuildOfRulesAndContainer();
        }
        HeapDump.dumpHeap( "heap.bin", true );
        st.done(null);
    }
{code}

To take that dump I added a specific test class among our tests: https://github.com/droolsjbpm/drools/blob/master/drools-core/src/test/java/org/drools/core/util/HeapDump.java

Regardless of how many loops I do, I always see only 2 instances of that PackageClassLoader class on my heap (see the screenshot I attached) and this confirms my first impression that we don't have any leak here.

Consider that I tested this against our master. Please use a newer drools version (6.5.0.Final should be available before the end of this week) and try to do the same.

> 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, 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)



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)