[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1313:
-------------------------------------
What I think it is not supported or anyway incorrect is keep reusing the same releaseId. Drools 6.x has been designed with a maven-like approach and you cannot deploy 2 artifacts with the same releaseId on a maven repository. To be honest I'm also surprised that the incremental compilation keeps working in that case and I'd need to debug your first reproducer to figure out why it is working even if I didn't expect this (and of course I cannot guarantee it will work in future).
> 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)
9 years, 7 months
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Bill Tuminaro commented on DROOLS-1313:
---------------------------------------
In my last round of testing, I used Drools 6.3.0.final and Drools 6.5.0CR2 - the results are the same.
-BillT
> 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)
9 years, 7 months
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Bill Tuminaro reopened DROOLS-1313:
-----------------------------------
I followed your code suggestion and added the loop 10 times to main. I see results that are similar to yours, memory usage does not seem to grow incrementally. THANK YOU !!
Now, I am back to my original question. Our code is written similar to the 1st reproducer I attached (SAVE_SimpleTest.java) which uses a different approach than the other code (SAVE_SimpleTest4.java). Basically the 1st reproducer uses a single releaseId and a single KieFileSystem. It just changes the contents of the file system and does an incremental build. I added the code to remove the old module "KieServices.Factory.get().getRepository().removeKieModule( )", however it seems memory continues to grow using this approach.
What is the correct way to make incremental changes to a KieFileSystem and use ((InternalKieBuilder) kb ).incrementalBuild() to build it? BTW, we use stateful sessions and are trying to keep the state intact between builds.
> 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)
9 years, 7 months
[JBoss JIRA] (WFLY-5542) Look into using apache's upstream JSTL
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5542?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka commented on WFLY-5542:
----------------------------------------
I agree with [~ctomc] that it is better to use secure by default. I believe to achieve some behavior you might need to set secure to false (operation which are not by default safe). Those features required user to know what he is doing as he can be more easily exposed to some attacks (I believe allowing to use some external includes or something similar). I am OK with this change, if such use case is found valid, it can be easily solved by adding system property allowing to switch the secure to false.
> Look into using apache's upstream JSTL
> --------------------------------------
>
> Key: WFLY-5542
> URL: https://issues.jboss.org/browse/WFLY-5542
> Project: WildFly
> Issue Type: Task
> Components: EE, Web (Undertow)
> Affects Versions: 10.0.0.CR2
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
>
> We are now using forked combination of apache & java.net's version of JSTL.
> We should look into using upstream version if possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1863) Make CredentialReference thread safe
by Peter Skopek (JIRA)
Peter Skopek created WFCORE-1863:
------------------------------------
Summary: Make CredentialReference thread safe
Key: WFCORE-1863
URL: https://issues.jboss.org/browse/WFCORE-1863
Project: WildFly Core
Issue Type: Enhancement
Components: Security
Affects Versions: 3.0.0.Alpha9
Reporter: Peter Skopek
Assignee: Peter Skopek
CredentialReference is not thread safe nor documented that fact.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7260:
-----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
> Key: WFLY-7260
> URL: https://issues.jboss.org/browse/WFLY-7260
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7260:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
> Key: WFLY-7260
> URL: https://issues.jboss.org/browse/WFLY-7260
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months