Discussion:
Drools Execution Server memory leak?
Mike Reynolds
2011-06-28 18:37:19 UTC
Permalink
Using: 5.2.0.Final of drools camel server , JSON api, and a Stateless Session
We are making JSON calls to the camel (execution) server.  Our
end-to-end unit tests pass.  Our load tests, however, show that memory
is never reclaimed after each call to the rules engine.  After parsing
through a heap dump, we see the following path taking up over 800 meg of
memory:
(kagent) KnowledgeAgentImpl$ChangeSetNotificationDetector
(kbase) KnowledgeAgentImpl
(ruleBase) KnowledgeBaseImpl
(eventSupport) ReteooRuleBase
(listeners) RuleBaseEventSupport
(array) CopyOnWriteArrayList
ReteooWorkingMemory (around 864K of these)
The rule base is very small and simple - this is only a problem during a load test (or over the course of a weeks worth of calls).  We make the following call 10K times:
{
  "batch-execution": {
    "lookup": "ksession1",
    "commands": [
      {
        "insert": {
          "out-identifier": "tc_1",
          "object": {.....}
          }}]}}
The knowledge-services.xml configures :
 - kagent id="agent1" kbase="kbase1" new-instance="true"
 - ksession id="ksession1" type="stateless" kbase="kbase1" node="node1" 

The rules just update the inserted "timecard" fact.

Because I'm using a stateless session, I don't think I need to
dispose of the agent...and I don't think there is a way to call dispose
using the json/Execution Command api.

We are calling the camel (execution) server from a non-java
environment to process employee timecards entries and evaluate for
overtime calculations.

Thanks!
Mike
fx242
2011-08-08 15:35:27 UTC
Permalink
Hi,

We are having the same problem with a similar setup (drools 5.2.0 Final)
using stateless sessions and camel integration, using a KB with ~3000 rules.
Session memory is never reclaimed, and after some hours we got an out of
memory error. We still dont know the cause, but the profiler shows that
these objects are increasing rapidly:

org.drools.reteoo.BetaMemory 176.478
+176.163 (+55925 %) 6.893 kB
org.drools.core.util.LeftTupleList 175.467
+175.156 (+56320 %) 6.854 kB
org.drools.core.util.RightTupleList 172.806
+172.536 (+63902 %) 6.750 kB
org.drools.rule.ContextEntry[ ] 164.784
+164.724 (+274540 %) 2.659 kB
org.drools.core.util.Entry[ ]
160.520 +160.449 (+225985 %) 16.561 kB
org.drools.core.util.ObjectHashMap 158.309 +158.253
(+282595 %) 6.183 kB
org.drools.reteoo.AccumulateNode$AccumulateMemory 154.505 +154.503
(+7725150 %) 4.828 kB
org.mvel2.integration.impl.IndexVariableResolver 76.262 +76.234
(+272264 %) 1.787 kB

We used drools 5.1.1 before with no problems, so we think this leak is
upgrade related.
Regards,
TL


--
View this message in context: http://drools.46999.n3.nabble.com/rules-users-Drools-Execution-Server-memory-leak-tp3118864p3235954.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
Loading...