[JBoss JIRA] (DROOLS-1028) Drools 6.3.0.Final - high memory usage
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1028?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1028.
---------------------------------
Resolution: Cannot Reproduce Bug
I still cannot reproduce this issue. If you still have this problem feel free to reopen this ticket and attach you reproducer.
> Drools 6.3.0.Final - high memory usage
> --------------------------------------
>
> Key: DROOLS-1028
> URL: https://issues.jboss.org/browse/DROOLS-1028
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.1.0.Final, 6.3.0.Final
> Environment: Drools 6.3.0.Final on Windows, AIX and Linux
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: newSampleFile.drl, SampleRuleFile.drl, screenshot-1.png
>
>
> We have an application that completely wraps the drools run-time. The code creates rules, compiles them and manages the run-time. We are experiencing very high memory utilization in an environment with about 1000 rules. Memory continuously grows as we insert facts, I know this is expected, however the amount of growth seems unusually large. In one scenario, memory consumption jumps 200 MB after inserting about 4800 facts (each fact consumes about 200 bytes) and calling fireallrules. We are currently running with the phreak algorithm. I wrote some code that iterates over the facthandles to count the number of right tuple references once the insertion and fireallrules has completed. It shows over 10 million references. Can someone review the attached code to tell me if the approach is sound? Also, how do I identify the entire set of right tuples in memory, I would like to write some code to produce some data about them to give me some insight into what is causing so many right tuples and right tuple references to be created. If we can narrow this down, I would like to write a reproducer to isolate the large memory usage.
> for (Object obj : kSession.getObjects()) {
> if (obj == null) {
> RuleLogger.traceDebug( className, methodName,"Null object");
> }
> DefaultFactHandle factHandle = (DefaultFactHandle)kSession.getFactHandle(obj);
> if (factHandle != null) {
> RightTuple previous = factHandle.getLastRightTuple();
> int rtCount = 0;
> if (previous != null ) {
> ++rtCount;
> while (true) {
> previous = (RightTuple) previous.getNext();
> if (previous == null)
> break;
> ++rtCount;
> }
> }
> totalRighttuples += rtCount;
> }
> }
> ...
> String msg = "printStats() - WM has " +nm.length() + " nodes in NM array, " + activeNodesInNm + " active nodes, " + totalsmNetworkNodes+ " network nodes, " + totalsmPathMemories + " path memories, " +
> + totalRighttuples + " rightTuple references";
> Sample output:
> printStats() - WM has 14328 nodes in NM array, 4711 active nodes, 26396 network nodes, 4640 path memories, 10754655 rightTuple references
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (JBJCA-1318) list driven ExceptionSorter, StaleConnectionChecker
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1318?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1318:
------------------------------------------------
Chao Wang <chaowan(a)redhat.com> changed the Status of [bug 1320720|https://bugzilla.redhat.com/show_bug.cgi?id=1320720] from ASSIGNED to POST
> list driven ExceptionSorter, StaleConnectionChecker
> ---------------------------------------------------
>
> Key: JBJCA-1318
> URL: https://issues.jboss.org/browse/JBJCA-1318
> Project: IronJacamar
> Issue Type: Task
> Components: JDBC
> Reporter: Johnathon Lee
> Assignee: Johnathon Lee
> Priority: Minor
> Fix For: 1.2.8.Final
>
>
> Configuration defined ExceptionSorter, StaleConnectionChecker.
> Using an externally (from the implementation) defined "," separated list.
> Defined via '<config-property name=prop_name >value1,value2,value3</>' in the standalone/domain configuration files.
> ie:
> set via <config-property name="FatalExceptions">10099,10100,10101</>
> set via <config-property name="StaleExceptions">10099,10100,10101</>
> Documentation updated to reflect suggested error codes for vendor based upon the current implementations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFLY-6434) System property 'org.jboss.as.security.jacc-module' not always used
by Winfried Wasser (JIRA)
Winfried Wasser created WFLY-6434:
-------------------------------------
Summary: System property 'org.jboss.as.security.jacc-module' not always used
Key: WFLY-6434
URL: https://issues.jboss.org/browse/WFLY-6434
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 10.0.0.Final
Reporter: Winfried Wasser
Assignee: Darran Lofthouse
Priority: Blocker
Attachments: security.patch
JaccService of security subsystem does not use the system property 'org.jboss.as.security.jacc-module' for class loader.
Due to this "not using", the custom JACC module is not used.
This property was introduced by WFLY-5340
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFLY-6152) EJB timer scheduler log an Exception for an already canceled timer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6152?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6152:
-----------------------------------------------
Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1305960|https://bugzilla.redhat.com/show_bug.cgi?id=1305960] from MODIFIED to POST
> EJB timer scheduler log an Exception for an already canceled timer
> ------------------------------------------------------------------
>
> Key: WFLY-6152
> URL: https://issues.jboss.org/browse/WFLY-6152
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Priority: Minor
> Labels: timer, timers, timerservice
>
> If a timer is canceled inside of the @timeout method the scheduler will log an ERROR if the timer duration is longer than the intervall and an overlapping execution should be fired.
> This is due to internal validatons.
> This will not happen if the timer is canceled by an external process, here the scheduler is removed.
> The log message is like this:
> ERROR [org.jboss.as.ejb3] (EJB default - 3) WFLYEJB0164: Exception running timer task for timer [id=0bd9870b-568b-42f5-9bda-e1525c3500aa timedObjectId=ejb30-timer.ejb30-timer.SimpleTimerBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@53ba1a7f initialExpiration=Tue Feb 09 17:19:32 CET 2016 intervalDuration(in milli sec)=5000 nextExpiration=Tue Feb 09 17:19:37 CET 2016 timerState=CANCELED info=SimpleTimerInfo description=A timer started every 5 seconds] on EJB ejb30-timer.ejb30-timer.SimpleTimerBean: javax.ejb.NoSuchObjectLocalException: WFLYEJB0331: Timer was canceled
> at org.jboss.as.ejb3.timerservice.TimerImpl.assertTimerState(TimerImpl.java:459)
> at org.jboss.as.ejb3.timerservice.TimerImpl.isPersistent(TimerImpl.java:215)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.shouldRun(TimerServiceImpl.java:1117)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:124)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1221)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFLY-4533) Port jboss-as-messaging_1_5.xsd from EAP
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4533?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4533:
-----------------------------------------------
Mike McCune <mmccune(a)redhat.com> changed the Status of [bug 1212941|https://bugzilla.redhat.com/show_bug.cgi?id=1212941] from MODIFIED to POST
> Port jboss-as-messaging_1_5.xsd from EAP
> ----------------------------------------
>
> Key: WFLY-4533
> URL: https://issues.jboss.org/browse/WFLY-4533
> Project: WildFly
> Issue Type: Sub-task
> Components: JMS
> Reporter: Darran Lofthouse
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 9.0.0.CR1
>
>
> Unfortunately an incompatible change has been introduced in jboss-as-messaging_1_4.xsd within EAP, this Jira issue is to minimise the impact.
> EAP should have a new jboss-as-messaging_1_5.xsd added and the changes to the 1.4 schema reverted. The parser will be updated to support 1.5 and will remain quietly accepting the new element.
> In WildFly we need to forward port this new 1.5 schema and also update the 1.4 parser to quietly accept the new element.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years