4:21 a.m.
Hi guys,
With great improvements usually come instability for a while :)
Trunk has memory issue, probably a memory leak of a small object.
I've run ExmaminationBenchmarkApp with the program arg "short" 3 times
with the exact same configuration (it is a 100% reproducible run):
1) Before the true modify changes with 512m max memory
Succeeds (100 steps but even 10000 steps work) with no slow down.
2) After true modify changes with 512m max memory
Fails after 27 steps, starts slowing down at 24 steps.
3) After true modify changes with 1024m max memory
Fails after 57 steps, starts slowing down at 54 steps.
Both 2) and 3) fail with the exception:
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit
exceeded
So it's not a heap space error or a perm space error, but a GC overhead
limit instead. Literally this means it's doing more GC then running,
but 99% of the time this means that the heap is so full that the GC has
little or no free space to work with.
This kind of memory leak happens when the iteration make 101 objects but
only removes 100 objects and the iteration is run a lot (like 10000+ times).
You don't get a heap space error, because before that happens,
there is point where you have a garbaged collected free memory for 10
objects and a ungarbaged collected free memory for 100 objects. At that
point the GC is running over 98% of the time, which is a VM treshold and
the error is thrown,
even though 10 iterations later you would get a heap space error.
Logs:
1)
TODO
2)
2010-03-13 09:28:36,973 [main] INFO Step index (21), time spend (37245)
taking step (323 {D180|S9} @ 9 {D210} + 5 {C65} => 52 {D210}) out of
1402 accepted moves.
2010-03-13 09:28:38,454 [main] INFO Step index (22), time spend (38727)
taking step (367 {D190|S40} @ 28 {D210} + 5 {C65} => 19 {D210}) out of
1366 accepted moves.
2010-03-13 09:28:39,903 [main] INFO Step index (23), time spend (40176)
taking step (230 {D120|S15} @ 7 {D210} + 3 {C60} => 12 {D210}) out of
1366 accepted moves.
2010-03-13 09:28:43,901 [main] INFO Step index (24), time spend (44174)
taking step (190 {D90|S6} @ 1 {D210} + 3 {C60} <=> 205 {D120|S6} @ 8
{D210} + 6 {C111}) out of 1392 accepted moves.
2010-03-13 09:28:50,631 [main] INFO Step index (25), time spend (50904)
taking step (420 {D180|S6} @ 46 {D210} + 2 {C129} => 25 {D210}) out of
1396 accepted moves.
2010-03-13 09:29:06,184 [main] INFO Step index (26), time spend (66457)
taking step (211 {D180|S53} @ 15 {D210} + 0 {C260} => 23 {D210}) out of
1383 accepted moves.
2010-03-13 09:29:46,589 [main] INFO Step index (27), time spend
(106862) taking step (39 {D120|S15} @ 50 {D210} + 2 {C129} => 43 {D210})
out of 1383 accepted moves.
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit
exceeded
at java.util.HashMap.addEntry(HashMap.java:753)
at java.util.HashMap.put(HashMap.java:385)
at java.util.HashMap.putAll(HashMap.java:524)
at
org.drools.rule.GroupElement$Type.getOuterDeclarations(GroupElement.java:406)
at org.drools.rule.GroupElement.getOuterDeclarations(GroupElement.java:109)
at
org.drools.base.DefaultKnowledgeHelper.getDeclaration(DefaultKnowledgeHelper.java:213)
at
org.drools.planner.examples.examination.solver.Rule_periodSpread_0DefaultConsequenceInvoker.evaluate(Rule_periodSpread_0DefaultConsequenceInvoker.java:21)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:903)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:850)
at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1061)
at
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:741)
at
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:707)
...
3)
2010-03-13 09:47:38,303 [main] INFO Step index (55), time spend
(114213) taking step (186 {D90|S17} @ 24 {D210} + 5 {C65} <=> 516
{D180|S12} @ 15 {D210} + 0 {C260}) out of 1382 accepted moves.
2010-03-13 09:48:02,062 [main] INFO Step index (56), time spend
(137972) taking step (498 {D120|S17} @ 28 {D210} + 0 {C260} => 1 {C100})
out of 1389 accepted moves.
2010-03-13 09:48:35,748 [main] INFO Step index (57), time spend
(171658) taking step (15 {D135|S96} @ 16 {D210} + 1 {C100} <=> 164
{D180|S48} @ 3 {D210} + 0 {C260}) out of 1378 accepted moves.
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit
exceeded
at java.lang.Integer.valueOf(Integer.java:625)
at
org.drools.common.TruthMaintenanceSystem.removeLogicalDependencies(TruthMaintenanceSystem.java:180)
at
org.drools.common.AbstractWorkingMemory.removeLogicalDependencies(AbstractWorkingMemory.java:1455)
at
org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:266)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:176)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:57)
at
org.drools.reteoo.EvalConditionNode.modifyLeftTuple(EvalConditionNode.java:250)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(SingleLeftTupleSinkAdapter.java:198)
at org.drools.reteoo.JoinNode.modifyLeftTuple(JoinNode.java:304)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(SingleLeftTupleSinkAdapter.java:209)
at org.drools.reteoo.JoinNode.modifyRightTuple(JoinNode.java:221)
at org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:317)
at
org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject(CompositeObjectSinkAdapter.java:444)
at
org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject(CompositeObjectSinkAdapter.java:412)
at org.drools.reteoo.ObjectTypeNode.modifyObject(ObjectTypeNode.java:262)
at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:174)
at
org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1392)
at
org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1288)
--
With kind regards,
Geoffrey De Smet
6:54 p.m.
Interesting error.
One explanation of it:
http://stackoverflow.com/questions/1393486/what-means-the-error-message-j...
Sent from my phone.
On 13/03/2010, at 8:21 PM, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
wrote:
Hi guys,
With great improvements usually come instability for a while :)
Trunk has memory issue, probably a memory leak of a small object.
I've run ExmaminationBenchmarkApp with the program arg "short" 3 times
with the exact same configuration (it is a 100% reproducible run):
1) Before the true modify changes with 512m max memory
Succeeds (100 steps but even 10000 steps work) with no slow down.
2) After true modify changes with 512m max memory
Fails after 27 steps, starts slowing down at 24 steps.
3) After true modify changes with 1024m max memory
Fails after 57 steps, starts slowing down at 54 steps.
Both 2) and 3) fail with the exception:
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead
limit
exceeded
So it's not a heap space error or a perm space error, but a GC
overhead
limit instead. Literally this means it's doing more GC then running,
but 99% of the time this means that the heap is so full that the GC
has
little or no free space to work with.
This kind of memory leak happens when the iteration make 101 objects
but
only removes 100 objects and the iteration is run a lot (like 10000+
times).
You don't get a heap space error, because before that happens,
there is point where you have a garbaged collected free memory for 10
objects and a ungarbaged collected free memory for 100 objects. At
that
point the GC is running over 98% of the time, which is a VM treshold
and
the error is thrown,
even though 10 iterations later you would get a heap space error.
Logs:
1)
TODO
2)
2010-03-13 09:28:36,973 [main] INFO Step index (21), time spend
(37245)
taking step (323 {D180|S9} @ 9 {D210} + 5 {C65} => 52 {D210}) out of
1402 accepted moves.
2010-03-13 09:28:38,454 [main] INFO Step index (22), time spend
(38727)
taking step (367 {D190|S40} @ 28 {D210} + 5 {C65} => 19 {D210}) out of
1366 accepted moves.
2010-03-13 09:28:39,903 [main] INFO Step index (23), time spend
(40176)
taking step (230 {D120|S15} @ 7 {D210} + 3 {C60} => 12 {D210}) out of
1366 accepted moves.
2010-03-13 09:28:43,901 [main] INFO Step index (24), time spend
(44174)
taking step (190 {D90|S6} @ 1 {D210} + 3 {C60} <=> 205 {D120|S6} @ 8
{D210} + 6 {C111}) out of 1392 accepted moves.
2010-03-13 09:28:50,631 [main] INFO Step index (25), time spend
(50904)
taking step (420 {D180|S6} @ 46 {D210} + 2 {C129} => 25 {D210}) out of
1396 accepted moves.
2010-03-13 09:29:06,184 [main] INFO Step index (26), time spend
(66457)
taking step (211 {D180|S53} @ 15 {D210} + 0 {C260} => 23 {D210}) out
of
1383 accepted moves.
2010-03-13 09:29:46,589 [main] INFO Step index (27), time spend
(106862) taking step (39 {D120|S15} @ 50 {D210} + 2 {C129} => 43
{D210})
out of 1383 accepted moves.
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead
limit
exceeded
at java.util.HashMap.addEntry(HashMap.java:753)
at java.util.HashMap.put(HashMap.java:385)
at java.util.HashMap.putAll(HashMap.java:524)
at
org.drools.rule.GroupElement$Type.getOuterDeclarations
(GroupElement.java:406)
at org.drools.rule.GroupElement.getOuterDeclarations
(GroupElement.java:109)
at
org.drools.base.DefaultKnowledgeHelper.getDeclaration
(DefaultKnowledgeHelper.java:213)
at
org.drools.planner.examples.examination.solver.Rule_periodSpread_0DefaultConsequenceInvoker.evaluate(
Rule_periodSpread_0DefaultConsequenceInvoker.java:21)
at org.drools.common.DefaultAgenda.fireActivation
(DefaultAgenda.java:903)
at org.drools.common.DefaultAgenda.fireNextItem
(DefaultAgenda.java:850)
at org.drools.common.DefaultAgenda.fireAllRules
(DefaultAgenda.java:1061)
at
org.drools.common.AbstractWorkingMemory.fireAllRules
(AbstractWorkingMemory.java:741)
at
org.drools.common.AbstractWorkingMemory.fireAllRules
(AbstractWorkingMemory.java:707)
...
3)
2010-03-13 09:47:38,303 [main] INFO Step index (55), time spend
(114213) taking step (186 {D90|S17} @ 24 {D210} + 5 {C65} <=> 516
{D180|S12} @ 15 {D210} + 0 {C260}) out of 1382 accepted moves.
2010-03-13 09:48:02,062 [main] INFO Step index (56), time spend
(137972) taking step (498 {D120|S17} @ 28 {D210} + 0 {C260} => 1
{C100})
out of 1389 accepted moves.
2010-03-13 09:48:35,748 [main] INFO Step index (57), time spend
(171658) taking step (15 {D135|S96} @ 16 {D210} + 1 {C100} <=> 164
{D180|S48} @ 3 {D210} + 0 {C260}) out of 1378 accepted moves.
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead
limit
exceeded
at java.lang.Integer.valueOf(Integer.java:625)
at
org.drools.common.TruthMaintenanceSystem.removeLogicalDependencies
(TruthMaintenanceSystem.java:180)
at
org.drools.common.AbstractWorkingMemory.removeLogicalDependencies
(AbstractWorkingMemory.java:1455)
at
org.drools.reteoo.RuleTerminalNode.retractLeftTuple
(RuleTerminalNode.java:266)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(
SingleLeftTupleSinkAdapter.java:176)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(
SingleLeftTupleSinkAdapter.java:57)
at
org.drools.reteoo.EvalConditionNode.modifyLeftTuple
(EvalConditionNode.java:250)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
SingleLeftTupleSinkAdapter.java:198)
at org.drools.reteoo.JoinNode.modifyLeftTuple(JoinNode.java:304)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
SingleLeftTupleSinkAdapter.java:209)
at org.drools.reteoo.JoinNode.modifyRightTuple(JoinNode.java:221)
at org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:317)
at
org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject
(CompositeObjectSinkAdapter.java:444)
at
org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject
(CompositeObjectSinkAdapter.java:412)
at org.drools.reteoo.ObjectTypeNode.modifyObject
(ObjectTypeNode.java:262)
at org.drools.reteoo.EntryPointNode.modifyObject
(EntryPointNode.java:174)
at
org.drools.common.AbstractWorkingMemory.update
(AbstractWorkingMemory.java:1392)
at
org.drools.common.AbstractWorkingMemory.update
(AbstractWorkingMemory.java:1288)
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
8:50 p.m.
Isn't that what Geoffrey just said? :)
Anyone tried different GC approaches with this? Running with the concurrent collector
might be a useful stopgap until the object creation is tamped down.
--- On Sat, 3/13/10, Michael Neale <michael.neale(a)gmail.com> wrote:
From: Michael Neale <michael.neale(a)gmail.com>
Subject: Re: [rules-dev] memory issue (memory leak?) on trunk (probably due true modify
changes)
To: "Rules Dev List" <rules-dev(a)lists.jboss.org>
Cc: "rules-dev(a)lists.jboss.org" <rules-dev(a)lists.jboss.org>
Date: Saturday, March 13, 2010, 5:54 PM
Interesting error.
One explanation of it:
http://stackoverflow.com/questions/1393486/what-means-the-error-message-j...
Sent from my phone.
On 13/03/2010, at 8:21 PM, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
wrote:
> Hi guys,
>
> With great improvements usually come instability for a
while :)
> Trunk has memory issue, probably a memory leak of a
small object.
>
> I've run ExmaminationBenchmarkApp with the program arg
"short" 3 times
> with the exact same configuration (it is a 100%
reproducible run):
>
> 1) Before the true modify changes with 512m max
memory
> Succeeds (100 steps but even 10000 steps work) with no
slow down.
>
> 2) After true modify changes with 512m max memory
> Fails after 27 steps, starts slowing down at 24
steps.
>
> 3) After true modify changes with 1024m max memory
> Fails after 57 steps, starts slowing down at 54
steps.
>
> Both 2) and 3) fail with the exception:
> Exception in thread "main" java.lang.OutOfMemoryError:
GC overhead
> limit
> exceeded
>
> So it's not a heap space error or a perm space error,
but a GC
> overhead
> limit instead. Literally this means it's doing more GC
then running,
> but 99% of the time this means that the heap is so
full that the GC
> has
> little or no free space to work with.
> This kind of memory leak happens when the iteration
make 101 objects
> but
> only removes 100 objects and the iteration is run a
lot (like 10000+
> times).
> You don't get a heap space error, because before that
happens,
> there is point where you have a garbaged collected
free memory for 10
> objects and a ungarbaged collected free memory for 100
objects. At
> that
> point the GC is running over 98% of the time, which is
a VM treshold
> and
> the error is thrown,
> even though 10 iterations later you would get a heap
space error.
>
>
> Logs:
>
> 1)
> TODO
>
> 2)
> 2010-03-13 09:28:36,973 [main] INFO Step index
(21), time spend
> (37245)
> taking step (323 {D180|S9} @ 9 {D210} + 5 {C65} =>
52 {D210}) out of
> 1402 accepted moves.
> 2010-03-13 09:28:38,454 [main] INFO Step index
(22), time spend
> (38727)
> taking step (367 {D190|S40} @ 28 {D210} + 5 {C65}
=> 19 {D210}) out of
> 1366 accepted moves.
> 2010-03-13 09:28:39,903 [main] INFO Step index
(23), time spend
> (40176)
> taking step (230 {D120|S15} @ 7 {D210} + 3 {C60} =>
12 {D210}) out of
> 1366 accepted moves.
> 2010-03-13 09:28:43,901 [main] INFO Step index
(24), time spend
> (44174)
> taking step (190 {D90|S6} @ 1 {D210} + 3 {C60}
<=> 205 {D120|S6} @ 8
> {D210} + 6 {C111}) out of 1392 accepted moves.
> 2010-03-13 09:28:50,631 [main] INFO Step index
(25), time spend
> (50904)
> taking step (420 {D180|S6} @ 46 {D210} + 2 {C129}
=> 25 {D210}) out of
> 1396 accepted moves.
> 2010-03-13 09:29:06,184 [main] INFO Step index
(26), time spend
> (66457)
> taking step (211 {D180|S53} @ 15 {D210} + 0 {C260}
=> 23 {D210}) out
> of
> 1383 accepted moves.
> 2010-03-13 09:29:46,589 [main] INFO Step index
(27), time spend
> (106862) taking step (39 {D120|S15} @ 50 {D210} + 2
{C129} => 43
> {D210})
> out of 1383 accepted moves.
> Exception in thread "main" java.lang.OutOfMemoryError:
GC overhead
> limit
> exceeded
> at
java.util.HashMap.addEntry(HashMap.java:753)
> at
java.util.HashMap.put(HashMap.java:385)
> at
java.util.HashMap.putAll(HashMap.java:524)
> at
> org.drools.rule.GroupElement$Type.getOuterDeclarations
> (GroupElement.java:406)
> at
org.drools.rule.GroupElement.getOuterDeclarations
> (GroupElement.java:109)
> at
> org.drools.base.DefaultKnowledgeHelper.getDeclaration
> (DefaultKnowledgeHelper.java:213)
> at
>
org.drools.planner.examples.examination.solver.Rule_periodSpread_0DefaultConsequenceInvoker.evaluate(
> Rule_periodSpread_0DefaultConsequenceInvoker.java:21)
> at
org.drools.common.DefaultAgenda.fireActivation
> (DefaultAgenda.java:903)
> at
org.drools.common.DefaultAgenda.fireNextItem
> (DefaultAgenda.java:850)
> at
org.drools.common.DefaultAgenda.fireAllRules
> (DefaultAgenda.java:1061)
> at
> org.drools.common.AbstractWorkingMemory.fireAllRules
> (AbstractWorkingMemory.java:741)
> at
> org.drools.common.AbstractWorkingMemory.fireAllRules
> (AbstractWorkingMemory.java:707)
> ...
>
> 3)
> 2010-03-13 09:47:38,303 [main] INFO Step index
(55), time spend
> (114213) taking step (186 {D90|S17} @ 24 {D210} + 5
{C65} <=> 516
> {D180|S12} @ 15 {D210} + 0 {C260}) out of 1382
accepted moves.
> 2010-03-13 09:48:02,062 [main] INFO Step index
(56), time spend
> (137972) taking step (498 {D120|S17} @ 28 {D210} + 0
{C260} => 1
> {C100})
> out of 1389 accepted moves.
> 2010-03-13 09:48:35,748 [main] INFO Step index
(57), time spend
> (171658) taking step (15 {D135|S96} @ 16 {D210} + 1
{C100} <=> 164
> {D180|S48} @ 3 {D210} + 0 {C260}) out of 1378 accepted
moves.
> Exception in thread "main" java.lang.OutOfMemoryError:
GC overhead
> limit
> exceeded
> at
java.lang.Integer.valueOf(Integer.java:625)
> at
>
org.drools.common.TruthMaintenanceSystem.removeLogicalDependencies
> (TruthMaintenanceSystem.java:180)
> at
>
org.drools.common.AbstractWorkingMemory.removeLogicalDependencies
> (AbstractWorkingMemory.java:1455)
> at
> org.drools.reteoo.RuleTerminalNode.retractLeftTuple
> (RuleTerminalNode.java:266)
> at
>
org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(
> SingleLeftTupleSinkAdapter.java:176)
> at
>
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(
> SingleLeftTupleSinkAdapter.java:57)
> at
> org.drools.reteoo.EvalConditionNode.modifyLeftTuple
> (EvalConditionNode.java:250)
> at
>
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
> SingleLeftTupleSinkAdapter.java:198)
> at
org.drools.reteoo.JoinNode.modifyLeftTuple(JoinNode.java:304)
> at
>
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
> SingleLeftTupleSinkAdapter.java:209)
> at
org.drools.reteoo.JoinNode.modifyRightTuple(JoinNode.java:221)
> at
org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:317)
> at
>
org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject
> (CompositeObjectSinkAdapter.java:444)
> at
>
org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject
> (CompositeObjectSinkAdapter.java:412)
> at
org.drools.reteoo.ObjectTypeNode.modifyObject
> (ObjectTypeNode.java:262)
> at
org.drools.reteoo.EntryPointNode.modifyObject
> (EntryPointNode.java:174)
> at
> org.drools.common.AbstractWorkingMemory.update
> (AbstractWorkingMemory.java:1392)
> at
> org.drools.common.AbstractWorkingMemory.update
> (AbstractWorkingMemory.java:1288)
>
>
> --
> With kind regards,
> Geoffrey De Smet
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
8:54 p.m.
On 14/03/2010 01:50, Greg Barton wrote:
Isn't that what Geoffrey just said? :)
Anyone tried different GC approaches with this? Running with the concurrent collector
might be a useful stopgap until the object creation is tamped down.
The new algorithm should now have less objects created than before, so
this indicates something is wrong somewhere.
Mark
--- On Sat, 3/13/10, Michael Neale<michael.neale(a)gmail.com>
wrote:
> From: Michael Neale<michael.neale(a)gmail.com>
> Subject: Re: [rules-dev] memory issue (memory leak?) on trunk (probably due true
modify changes)
> To: "Rules Dev List"<rules-dev(a)lists.jboss.org>
> Cc: "rules-dev@lists.jboss.org"<rules-dev(a)lists.jboss.org>
> Date: Saturday, March 13, 2010, 5:54 PM
> Interesting error.
>
> One explanation of it:
http://stackoverflow.com/questions/1393486/what-means-the-error-message-j...
>
> Sent from my phone.
>
> On 13/03/2010, at 8:21 PM, Geoffrey De Smet<ge0ffrey.spam(a)gmail.com>
>
> wrote:
>
>
>> Hi guys,
>>
>> With great improvements usually come instability for a
>>
> while :)
>
>> Trunk has memory issue, probably a memory leak of a
>>
> small object.
>
>> I've run ExmaminationBenchmarkApp with the program arg
>>
> "short" 3 times
>
>> with the exact same configuration (it is a 100%
>>
> reproducible run):
>
>> 1) Before the true modify changes with 512m max
>>
> memory
>
>> Succeeds (100 steps but even 10000 steps work) with no
>>
> slow down.
>
>> 2) After true modify changes with 512m max memory
>> Fails after 27 steps, starts slowing down at 24
>>
> steps.
>
>> 3) After true modify changes with 1024m max memory
>> Fails after 57 steps, starts slowing down at 54
>>
> steps.
>
>> Both 2) and 3) fail with the exception:
>> Exception in thread "main" java.lang.OutOfMemoryError:
>>
> GC overhead
>
>> limit
>> exceeded
>>
>> So it's not a heap space error or a perm space error,
>>
> but a GC
>
>> overhead
>> limit instead. Literally this means it's doing more GC
>>
> then running,
>
>> but 99% of the time this means that the heap is so
>>
> full that the GC
>
>> has
>> little or no free space to work with.
>> This kind of memory leak happens when the iteration
>>
> make 101 objects
>
>> but
>> only removes 100 objects and the iteration is run a
>>
> lot (like 10000+
>
>> times).
>> You don't get a heap space error, because before that
>>
> happens,
>
>> there is point where you have a garbaged collected
>>
> free memory for 10
>
>> objects and a ungarbaged collected free memory for 100
>>
> objects. At
>
>> that
>> point the GC is running over 98% of the time, which is
>>
> a VM treshold
>
>> and
>> the error is thrown,
>> even though 10 iterations later you would get a heap
>>
> space error.
>
>>
>> Logs:
>>
>> 1)
>> TODO
>>
>> 2)
>> 2010-03-13 09:28:36,973 [main] INFO Step index
>>
> (21), time spend
>
>> (37245)
>> taking step (323 {D180|S9} @ 9 {D210} + 5 {C65} =>
>>
> 52 {D210}) out of
>
>> 1402 accepted moves.
>> 2010-03-13 09:28:38,454 [main] INFO Step index
>>
> (22), time spend
>
>> (38727)
>> taking step (367 {D190|S40} @ 28 {D210} + 5 {C65}
>>
> => 19 {D210}) out of
>
>> 1366 accepted moves.
>> 2010-03-13 09:28:39,903 [main] INFO Step index
>>
> (23), time spend
>
>> (40176)
>> taking step (230 {D120|S15} @ 7 {D210} + 3 {C60} =>
>>
> 12 {D210}) out of
>
>> 1366 accepted moves.
>> 2010-03-13 09:28:43,901 [main] INFO Step index
>>
> (24), time spend
>
>> (44174)
>> taking step (190 {D90|S6} @ 1 {D210} + 3 {C60}
>>
> <=> 205 {D120|S6} @ 8
>
>> {D210} + 6 {C111}) out of 1392 accepted moves.
>> 2010-03-13 09:28:50,631 [main] INFO Step index
>>
> (25), time spend
>
>> (50904)
>> taking step (420 {D180|S6} @ 46 {D210} + 2 {C129}
>>
> => 25 {D210}) out of
>
>> 1396 accepted moves.
>> 2010-03-13 09:29:06,184 [main] INFO Step index
>>
> (26), time spend
>
>> (66457)
>> taking step (211 {D180|S53} @ 15 {D210} + 0 {C260}
>>
> => 23 {D210}) out
>
>> of
>> 1383 accepted moves.
>> 2010-03-13 09:29:46,589 [main] INFO Step index
>>
> (27), time spend
>
>> (106862) taking step (39 {D120|S15} @ 50 {D210} + 2
>>
> {C129} => 43
>
>> {D210})
>> out of 1383 accepted moves.
>> Exception in thread "main" java.lang.OutOfMemoryError:
>>
> GC overhead
>
>> limit
>> exceeded
>> at
>>
> java.util.HashMap.addEntry(HashMap.java:753)
>
>> at
>>
> java.util.HashMap.put(HashMap.java:385)
>
>> at
>>
> java.util.HashMap.putAll(HashMap.java:524)
>
>> at
>> org.drools.rule.GroupElement$Type.getOuterDeclarations
>>
>
>> (GroupElement.java:406)
>> at
>>
> org.drools.rule.GroupElement.getOuterDeclarations
>
>> (GroupElement.java:109)
>> at
>> org.drools.base.DefaultKnowledgeHelper.getDeclaration
>>
>
>> (DefaultKnowledgeHelper.java:213)
>> at
>>
>>
>
org.drools.planner.examples.examination.solver.Rule_periodSpread_0DefaultConsequenceInvoker.evaluate(
>
>
>> Rule_periodSpread_0DefaultConsequenceInvoker.java:21)
>> at
>>
> org.drools.common.DefaultAgenda.fireActivation
>
>> (DefaultAgenda.java:903)
>> at
>>
> org.drools.common.DefaultAgenda.fireNextItem
>
>> (DefaultAgenda.java:850)
>> at
>>
> org.drools.common.DefaultAgenda.fireAllRules
>
>> (DefaultAgenda.java:1061)
>> at
>> org.drools.common.AbstractWorkingMemory.fireAllRules
>> (AbstractWorkingMemory.java:741)
>> at
>> org.drools.common.AbstractWorkingMemory.fireAllRules
>> (AbstractWorkingMemory.java:707)
>> ...
>>
>> 3)
>> 2010-03-13 09:47:38,303 [main] INFO Step index
>>
> (55), time spend
>
>> (114213) taking step (186 {D90|S17} @ 24 {D210} + 5
>>
> {C65}<=> 516
>
>> {D180|S12} @ 15 {D210} + 0 {C260}) out of 1382
>>
> accepted moves.
>
>> 2010-03-13 09:48:02,062 [main] INFO Step index
>>
> (56), time spend
>
>> (137972) taking step (498 {D120|S17} @ 28 {D210} + 0
>>
> {C260} => 1
>
>> {C100})
>> out of 1389 accepted moves.
>> 2010-03-13 09:48:35,748 [main] INFO Step index
>>
> (57), time spend
>
>> (171658) taking step (15 {D135|S96} @ 16 {D210} + 1
>>
> {C100}<=> 164
>
>> {D180|S48} @ 3 {D210} + 0 {C260}) out of 1378 accepted
>>
> moves.
>
>> Exception in thread "main" java.lang.OutOfMemoryError:
>>
> GC overhead
>
>> limit
>> exceeded
>> at
>>
> java.lang.Integer.valueOf(Integer.java:625)
>
>> at
>>
>>
> org.drools.common.TruthMaintenanceSystem.removeLogicalDependencies
>
>
>> (TruthMaintenanceSystem.java:180)
>> at
>>
>>
> org.drools.common.AbstractWorkingMemory.removeLogicalDependencies
>
>
>> (AbstractWorkingMemory.java:1455)
>> at
>> org.drools.reteoo.RuleTerminalNode.retractLeftTuple
>> (RuleTerminalNode.java:266)
>> at
>>
>>
> org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(
>
>
>> SingleLeftTupleSinkAdapter.java:176)
>> at
>>
>>
> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(
>
>
>> SingleLeftTupleSinkAdapter.java:57)
>> at
>> org.drools.reteoo.EvalConditionNode.modifyLeftTuple
>> (EvalConditionNode.java:250)
>> at
>>
>>
> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
>
>
>> SingleLeftTupleSinkAdapter.java:198)
>> at
>>
> org.drools.reteoo.JoinNode.modifyLeftTuple(JoinNode.java:304)
>
>> at
>>
>>
> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
>
>
>> SingleLeftTupleSinkAdapter.java:209)
>> at
>>
> org.drools.reteoo.JoinNode.modifyRightTuple(JoinNode.java:221)
>
>> at
>>
> org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:317)
>
>> at
>>
>>
> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject
>
>
>> (CompositeObjectSinkAdapter.java:444)
>> at
>>
>>
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject
>
>
>> (CompositeObjectSinkAdapter.java:412)
>> at
>>
> org.drools.reteoo.ObjectTypeNode.modifyObject
>
>> (ObjectTypeNode.java:262)
>> at
>>
> org.drools.reteoo.EntryPointNode.modifyObject
>
>> (EntryPointNode.java:174)
>> at
>> org.drools.common.AbstractWorkingMemory.update
>> (AbstractWorkingMemory.java:1392)
>> at
>> org.drools.common.AbstractWorkingMemory.update
>> (AbstractWorkingMemory.java:1288)
>>
>>
>> --
>> With kind regards,
>> Geoffrey De Smet
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
7:15 a.m.
I agree with Mark, between a debug breakpoint and VisualVM's memory
snapshot it should be clear which small objects leak.
With kind regards,
Geoffrey De Smet
Mark Proctor schreef:
On 14/03/2010 01:50, Greg Barton wrote:
> Isn't that what Geoffrey just said? :)
>
> Anyone tried different GC approaches with this? Running with the concurrent
collector might be a useful stopgap until the object creation is tamped down.
>
The new algorithm should now have less objects created than before, so
this indicates something is wrong somewhere.
Mark
> --- On Sat, 3/13/10, Michael Neale<michael.neale(a)gmail.com> wrote:
>
>
>> From: Michael Neale<michael.neale(a)gmail.com>
>> Subject: Re: [rules-dev] memory issue (memory leak?) on trunk (probably due true
modify changes)
>> To: "Rules Dev List"<rules-dev(a)lists.jboss.org>
>> Cc: "rules-dev@lists.jboss.org"<rules-dev(a)lists.jboss.org>
>> Date: Saturday, March 13, 2010, 5:54 PM
>> Interesting error.
>>
>> One explanation of it:
http://stackoverflow.com/questions/1393486/what-means-the-error-message-j...
>>
>> Sent from my phone.
>>
>> On 13/03/2010, at 8:21 PM, Geoffrey De Smet<ge0ffrey.spam(a)gmail.com>
>>
>> wrote:
>>
>>
>>> Hi guys,
>>>
>>> With great improvements usually come instability for a
>>>
>> while :)
>>
>>> Trunk has memory issue, probably a memory leak of a
>>>
>> small object.
>>
>>> I've run ExmaminationBenchmarkApp with the program arg
>>>
>> "short" 3 times
>>
>>> with the exact same configuration (it is a 100%
>>>
>> reproducible run):
>>
>>> 1) Before the true modify changes with 512m max
>>>
>> memory
>>
>>> Succeeds (100 steps but even 10000 steps work) with no
>>>
>> slow down.
>>
>>> 2) After true modify changes with 512m max memory
>>> Fails after 27 steps, starts slowing down at 24
>>>
>> steps.
>>
>>> 3) After true modify changes with 1024m max memory
>>> Fails after 57 steps, starts slowing down at 54
>>>
>> steps.
>>
>>> Both 2) and 3) fail with the exception:
>>> Exception in thread "main" java.lang.OutOfMemoryError:
>>>
>> GC overhead
>>
>>> limit
>>> exceeded
>>>
>>> So it's not a heap space error or a perm space error,
>>>
>> but a GC
>>
>>> overhead
>>> limit instead. Literally this means it's doing more GC
>>>
>> then running,
>>
>>> but 99% of the time this means that the heap is so
>>>
>> full that the GC
>>
>>> has
>>> little or no free space to work with.
>>> This kind of memory leak happens when the iteration
>>>
>> make 101 objects
>>
>>> but
>>> only removes 100 objects and the iteration is run a
>>>
>> lot (like 10000+
>>
>>> times).
>>> You don't get a heap space error, because before that
>>>
>> happens,
>>
>>> there is point where you have a garbaged collected
>>>
>> free memory for 10
>>
>>> objects and a ungarbaged collected free memory for 100
>>>
>> objects. At
>>
>>> that
>>> point the GC is running over 98% of the time, which is
>>>
>> a VM treshold
>>
>>> and
>>> the error is thrown,
>>> even though 10 iterations later you would get a heap
>>>
>> space error.
>>
>>> Logs:
>>>
>>> 1)
>>> TODO
>>>
>>> 2)
>>> 2010-03-13 09:28:36,973 [main] INFO Step index
>>>
>> (21), time spend
>>
>>> (37245)
>>> taking step (323 {D180|S9} @ 9 {D210} + 5 {C65} =>
>>>
>> 52 {D210}) out of
>>
>>> 1402 accepted moves.
>>> 2010-03-13 09:28:38,454 [main] INFO Step index
>>>
>> (22), time spend
>>
>>> (38727)
>>> taking step (367 {D190|S40} @ 28 {D210} + 5 {C65}
>>>
>> => 19 {D210}) out of
>>
>>> 1366 accepted moves.
>>> 2010-03-13 09:28:39,903 [main] INFO Step index
>>>
>> (23), time spend
>>
>>> (40176)
>>> taking step (230 {D120|S15} @ 7 {D210} + 3 {C60} =>
>>>
>> 12 {D210}) out of
>>
>>> 1366 accepted moves.
>>> 2010-03-13 09:28:43,901 [main] INFO Step index
>>>
>> (24), time spend
>>
>>> (44174)
>>> taking step (190 {D90|S6} @ 1 {D210} + 3 {C60}
>>>
>> <=> 205 {D120|S6} @ 8
>>
>>> {D210} + 6 {C111}) out of 1392 accepted moves.
>>> 2010-03-13 09:28:50,631 [main] INFO Step index
>>>
>> (25), time spend
>>
>>> (50904)
>>> taking step (420 {D180|S6} @ 46 {D210} + 2 {C129}
>>>
>> => 25 {D210}) out of
>>
>>> 1396 accepted moves.
>>> 2010-03-13 09:29:06,184 [main] INFO Step index
>>>
>> (26), time spend
>>
>>> (66457)
>>> taking step (211 {D180|S53} @ 15 {D210} + 0 {C260}
>>>
>> => 23 {D210}) out
>>
>>> of
>>> 1383 accepted moves.
>>> 2010-03-13 09:29:46,589 [main] INFO Step index
>>>
>> (27), time spend
>>
>>> (106862) taking step (39 {D120|S15} @ 50 {D210} + 2
>>>
>> {C129} => 43
>>
>>> {D210})
>>> out of 1383 accepted moves.
>>> Exception in thread "main" java.lang.OutOfMemoryError:
>>>
>> GC overhead
>>
>>> limit
>>> exceeded
>>> at
>>>
>> java.util.HashMap.addEntry(HashMap.java:753)
>>
>>> at
>>>
>> java.util.HashMap.put(HashMap.java:385)
>>
>>> at
>>>
>> java.util.HashMap.putAll(HashMap.java:524)
>>
>>> at
>>> org.drools.rule.GroupElement$Type.getOuterDeclarations
>>>
>>
>>> (GroupElement.java:406)
>>> at
>>>
>> org.drools.rule.GroupElement.getOuterDeclarations
>>
>>> (GroupElement.java:109)
>>> at
>>> org.drools.base.DefaultKnowledgeHelper.getDeclaration
>>>
>>
>>> (DefaultKnowledgeHelper.java:213)
>>> at
>>>
>>>
>>
org.drools.planner.examples.examination.solver.Rule_periodSpread_0DefaultConsequenceInvoker.evaluate(
>>
>>
>>> Rule_periodSpread_0DefaultConsequenceInvoker.java:21)
>>> at
>>>
>> org.drools.common.DefaultAgenda.fireActivation
>>
>>> (DefaultAgenda.java:903)
>>> at
>>>
>> org.drools.common.DefaultAgenda.fireNextItem
>>
>>> (DefaultAgenda.java:850)
>>> at
>>>
>> org.drools.common.DefaultAgenda.fireAllRules
>>
>>> (DefaultAgenda.java:1061)
>>> at
>>> org.drools.common.AbstractWorkingMemory.fireAllRules
>>> (AbstractWorkingMemory.java:741)
>>> at
>>> org.drools.common.AbstractWorkingMemory.fireAllRules
>>> (AbstractWorkingMemory.java:707)
>>> ...
>>>
>>> 3)
>>> 2010-03-13 09:47:38,303 [main] INFO Step index
>>>
>> (55), time spend
>>
>>> (114213) taking step (186 {D90|S17} @ 24 {D210} + 5
>>>
>> {C65}<=> 516
>>
>>> {D180|S12} @ 15 {D210} + 0 {C260}) out of 1382
>>>
>> accepted moves.
>>
>>> 2010-03-13 09:48:02,062 [main] INFO Step index
>>>
>> (56), time spend
>>
>>> (137972) taking step (498 {D120|S17} @ 28 {D210} + 0
>>>
>> {C260} => 1
>>
>>> {C100})
>>> out of 1389 accepted moves.
>>> 2010-03-13 09:48:35,748 [main] INFO Step index
>>>
>> (57), time spend
>>
>>> (171658) taking step (15 {D135|S96} @ 16 {D210} + 1
>>>
>> {C100}<=> 164
>>
>>> {D180|S48} @ 3 {D210} + 0 {C260}) out of 1378 accepted
>>>
>> moves.
>>
>>> Exception in thread "main" java.lang.OutOfMemoryError:
>>>
>> GC overhead
>>
>>> limit
>>> exceeded
>>> at
>>>
>> java.lang.Integer.valueOf(Integer.java:625)
>>
>>> at
>>>
>>>
>> org.drools.common.TruthMaintenanceSystem.removeLogicalDependencies
>>
>>
>>> (TruthMaintenanceSystem.java:180)
>>> at
>>>
>>>
>> org.drools.common.AbstractWorkingMemory.removeLogicalDependencies
>>
>>
>>> (AbstractWorkingMemory.java:1455)
>>> at
>>> org.drools.reteoo.RuleTerminalNode.retractLeftTuple
>>> (RuleTerminalNode.java:266)
>>> at
>>>
>>>
>> org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(
>>
>>
>>> SingleLeftTupleSinkAdapter.java:176)
>>> at
>>>
>>>
>> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(
>>
>>
>>> SingleLeftTupleSinkAdapter.java:57)
>>> at
>>> org.drools.reteoo.EvalConditionNode.modifyLeftTuple
>>> (EvalConditionNode.java:250)
>>> at
>>>
>>>
>> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
>>
>>
>>> SingleLeftTupleSinkAdapter.java:198)
>>> at
>>>
>> org.drools.reteoo.JoinNode.modifyLeftTuple(JoinNode.java:304)
>>
>>> at
>>>
>>>
>> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
>>
>>
>>> SingleLeftTupleSinkAdapter.java:209)
>>> at
>>>
>> org.drools.reteoo.JoinNode.modifyRightTuple(JoinNode.java:221)
>>
>>> at
>>>
>> org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:317)
>>
>>> at
>>>
>>>
>> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject
>>
>>
>>> (CompositeObjectSinkAdapter.java:444)
>>> at
>>>
>>>
>> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject
>>
>>
>>> (CompositeObjectSinkAdapter.java:412)
>>> at
>>>
>> org.drools.reteoo.ObjectTypeNode.modifyObject
>>
>>> (ObjectTypeNode.java:262)
>>> at
>>>
>> org.drools.reteoo.EntryPointNode.modifyObject
>>
>>> (EntryPointNode.java:174)
>>> at
>>> org.drools.common.AbstractWorkingMemory.update
>>> (AbstractWorkingMemory.java:1392)
>>> at
>>> org.drools.common.AbstractWorkingMemory.update
>>> (AbstractWorkingMemory.java:1288)
>>>
>>>
>>> --
>>> With kind regards,
>>> Geoffrey De Smet
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
10:24 p.m.
well it is interesting that it means 98% of the time it is GC doing the
work. Think about that - that means if it is only 90% GC doing the work (ie
90% of CPU time is spent running the garbage collector - and freeing enough
memory to keep it happy) than it would not trip this error - but I am sure
no one would be happy with an application that runs that way !
On Sun, Mar 14, 2010 at 12:50 PM, Greg Barton <greg_barton(a)yahoo.com> wrote:
Isn't that what Geoffrey just said? :)
Anyone tried different GC approaches with this? Running with the
concurrent collector might be a useful stopgap until the object creation is
tamped down.
--- On Sat, 3/13/10, Michael Neale <michael.neale(a)gmail.com> wrote:
> From: Michael Neale <michael.neale(a)gmail.com>
> Subject: Re: [rules-dev] memory issue (memory leak?) on trunk (probably
due true modify changes)
> To: "Rules Dev List" <rules-dev(a)lists.jboss.org>
> Cc: "rules-dev(a)lists.jboss.org" <rules-dev(a)lists.jboss.org>
> Date: Saturday, March 13, 2010, 5:54 PM
> Interesting error.
>
> One explanation of it:
http://stackoverflow.com/questions/1393486/what-means-the-error-message-j...
>
> Sent from my phone.
>
> On 13/03/2010, at 8:21 PM, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
>
> wrote:
>
> > Hi guys,
> >
> > With great improvements usually come instability for a
> while :)
> > Trunk has memory issue, probably a memory leak of a
> small object.
> >
> > I've run ExmaminationBenchmarkApp with the program arg
> "short" 3 times
> > with the exact same configuration (it is a 100%
> reproducible run):
> >
> > 1) Before the true modify changes with 512m max
> memory
> > Succeeds (100 steps but even 10000 steps work) with no
> slow down.
> >
> > 2) After true modify changes with 512m max memory
> > Fails after 27 steps, starts slowing down at 24
> steps.
> >
> > 3) After true modify changes with 1024m max memory
> > Fails after 57 steps, starts slowing down at 54
> steps.
> >
> > Both 2) and 3) fail with the exception:
> > Exception in thread "main" java.lang.OutOfMemoryError:
> GC overhead
> > limit
> > exceeded
> >
> > So it's not a heap space error or a perm space error,
> but a GC
> > overhead
> > limit instead. Literally this means it's doing more GC
> then running,
> > but 99% of the time this means that the heap is so
> full that the GC
> > has
> > little or no free space to work with.
> > This kind of memory leak happens when the iteration
> make 101 objects
> > but
> > only removes 100 objects and the iteration is run a
> lot (like 10000+
> > times).
> > You don't get a heap space error, because before that
> happens,
> > there is point where you have a garbaged collected
> free memory for 10
> > objects and a ungarbaged collected free memory for 100
> objects. At
> > that
> > point the GC is running over 98% of the time, which is
> a VM treshold
> > and
> > the error is thrown,
> > even though 10 iterations later you would get a heap
> space error.
> >
> >
> > Logs:
> >
> > 1)
> > TODO
> >
> > 2)
> > 2010-03-13 09:28:36,973 [main] INFO Step index
> (21), time spend
> > (37245)
> > taking step (323 {D180|S9} @ 9 {D210} + 5 {C65} =>
> 52 {D210}) out of
> > 1402 accepted moves.
> > 2010-03-13 09:28:38,454 [main] INFO Step index
> (22), time spend
> > (38727)
> > taking step (367 {D190|S40} @ 28 {D210} + 5 {C65}
> => 19 {D210}) out of
> > 1366 accepted moves.
> > 2010-03-13 09:28:39,903 [main] INFO Step index
> (23), time spend
> > (40176)
> > taking step (230 {D120|S15} @ 7 {D210} + 3 {C60} =>
> 12 {D210}) out of
> > 1366 accepted moves.
> > 2010-03-13 09:28:43,901 [main] INFO Step index
> (24), time spend
> > (44174)
> > taking step (190 {D90|S6} @ 1 {D210} + 3 {C60}
> <=> 205 {D120|S6} @ 8
> > {D210} + 6 {C111}) out of 1392 accepted moves.
> > 2010-03-13 09:28:50,631 [main] INFO Step index
> (25), time spend
> > (50904)
> > taking step (420 {D180|S6} @ 46 {D210} + 2 {C129}
> => 25 {D210}) out of
> > 1396 accepted moves.
> > 2010-03-13 09:29:06,184 [main] INFO Step index
> (26), time spend
> > (66457)
> > taking step (211 {D180|S53} @ 15 {D210} + 0 {C260}
> => 23 {D210}) out
> > of
> > 1383 accepted moves.
> > 2010-03-13 09:29:46,589 [main] INFO Step index
> (27), time spend
> > (106862) taking step (39 {D120|S15} @ 50 {D210} + 2
> {C129} => 43
> > {D210})
> > out of 1383 accepted moves.
> > Exception in thread "main" java.lang.OutOfMemoryError:
> GC overhead
> > limit
> > exceeded
> > at
> java.util.HashMap.addEntry(HashMap.java:753)
> > at
> java.util.HashMap.put(HashMap.java:385)
> > at
> java.util.HashMap.putAll(HashMap.java:524)
> > at
> > org.drools.rule.GroupElement$Type.getOuterDeclarations
>
> > (GroupElement.java:406)
> > at
> org.drools.rule.GroupElement.getOuterDeclarations
> > (GroupElement.java:109)
> > at
> > org.drools.base.DefaultKnowledgeHelper.getDeclaration
>
> > (DefaultKnowledgeHelper.java:213)
> > at
> >
>
org.drools.planner.examples.examination.solver.Rule_periodSpread_0DefaultConsequenceInvoker.evaluate(
>
> > Rule_periodSpread_0DefaultConsequenceInvoker.java:21)
> > at
> org.drools.common.DefaultAgenda.fireActivation
> > (DefaultAgenda.java:903)
> > at
> org.drools.common.DefaultAgenda.fireNextItem
> > (DefaultAgenda.java:850)
> > at
> org.drools.common.DefaultAgenda.fireAllRules
> > (DefaultAgenda.java:1061)
> > at
> > org.drools.common.AbstractWorkingMemory.fireAllRules
> > (AbstractWorkingMemory.java:741)
> > at
> > org.drools.common.AbstractWorkingMemory.fireAllRules
> > (AbstractWorkingMemory.java:707)
> > ...
> >
> > 3)
> > 2010-03-13 09:47:38,303 [main] INFO Step index
> (55), time spend
> > (114213) taking step (186 {D90|S17} @ 24 {D210} + 5
> {C65} <=> 516
> > {D180|S12} @ 15 {D210} + 0 {C260}) out of 1382
> accepted moves.
> > 2010-03-13 09:48:02,062 [main] INFO Step index
> (56), time spend
> > (137972) taking step (498 {D120|S17} @ 28 {D210} + 0
> {C260} => 1
> > {C100})
> > out of 1389 accepted moves.
> > 2010-03-13 09:48:35,748 [main] INFO Step index
> (57), time spend
> > (171658) taking step (15 {D135|S96} @ 16 {D210} + 1
> {C100} <=> 164
> > {D180|S48} @ 3 {D210} + 0 {C260}) out of 1378 accepted
> moves.
> > Exception in thread "main" java.lang.OutOfMemoryError:
> GC overhead
> > limit
> > exceeded
> > at
> java.lang.Integer.valueOf(Integer.java:625)
> > at
> >
> org.drools.common.TruthMaintenanceSystem.removeLogicalDependencies
>
> > (TruthMaintenanceSystem.java:180)
> > at
> >
> org.drools.common.AbstractWorkingMemory.removeLogicalDependencies
>
> > (AbstractWorkingMemory.java:1455)
> > at
> > org.drools.reteoo.RuleTerminalNode.retractLeftTuple
> > (RuleTerminalNode.java:266)
> > at
> >
> org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(
>
> > SingleLeftTupleSinkAdapter.java:176)
> > at
> >
> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(
>
> > SingleLeftTupleSinkAdapter.java:57)
> > at
> > org.drools.reteoo.EvalConditionNode.modifyLeftTuple
> > (EvalConditionNode.java:250)
> > at
> >
>
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
>
> > SingleLeftTupleSinkAdapter.java:198)
> > at
> org.drools.reteoo.JoinNode.modifyLeftTuple(JoinNode.java:304)
> > at
> >
>
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateModifyChildLeftTuple(
>
> > SingleLeftTupleSinkAdapter.java:209)
> > at
> org.drools.reteoo.JoinNode.modifyRightTuple(JoinNode.java:221)
> > at
> org.drools.reteoo.BetaNode.modifyObject(BetaNode.java:317)
> > at
> >
> org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateModifyObject
>
> > (CompositeObjectSinkAdapter.java:444)
> > at
> >
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateModifyObject
>
> > (CompositeObjectSinkAdapter.java:412)
> > at
> org.drools.reteoo.ObjectTypeNode.modifyObject
> > (ObjectTypeNode.java:262)
> > at
> org.drools.reteoo.EntryPointNode.modifyObject
> > (EntryPointNode.java:174)
> > at
> > org.drools.common.AbstractWorkingMemory.update
> > (AbstractWorkingMemory.java:1392)
> > at
> > org.drools.common.AbstractWorkingMemory.update
> > (AbstractWorkingMemory.java:1288)
> >
> >
> > --
> > With kind regards,
> > Geoffrey De Smet
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
5154
days inactive
5155
days old
5 comments
4 participants
participants (4)
-
Geoffrey De Smet -
Greg Barton -
Mark Proctor -
Michael Neale