<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
If <br>
- the equals/hashCode contract is followed (see Object#equals)<br>
- even when considering that your output is suffering from
<a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/JBRULES-3505">https://issues.jboss.org/browse/JBRULES-3505</a> - it's unlogical that
the rule behaves as it does<br>
<br>
then it could be a "stateful memory corruption".<br>
To prove that it is, first write a SimpleJavaScoreCalculator (see
docs). That will be a lot slower, but it won't suffer from the
issue.<br>
Next, switch back and use this recipe to isolate that "stateful
memory corruption" into a Drools Expert unit test, so we can fix it:<br>
<blockquote type="cite">here's how I usually isolate such a bug to a
small reproducable unit test:<br>
<br>
- Turn on environmentMode TRACE so it crashes as fast as possible<br>
- Turn on TRACE logging.<br>
<a
href="http://docs.jboss.org/drools/release/5.4.0.Beta1/drools-planner-docs/html_single/index.html#d0e2450">http://docs.jboss.org/drools/release/5.4.0.Beta1/drools-planner-docs/html_single/index.html#d0e2450</a><br>
So you see something like this:<br>
<a id="d0e4083" style="color: rgb(51, 51, 51); font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: 18px; orphans: 2; text-align: justify; text-indent:
0px; text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px;">
<pre class="" style="font-size: 0.9em; font-family: courrier,monospace; display: block; background-color: rgb(245, 245, 245); color: rgb(51, 51, 51); overflow: auto; padding: 5px 15px 5px 25px; border: 1px solid rgb(204, 204, 204);">INFO Solver started: time spend (0), score (-6), new best score (-6), random seed (0).
TRACE Ignoring not doable move (col0@row0 => row0).
TRACE Move score (-4), accepted (true) for move (col0@row0 => row1).
TRACE Move score (-4), accepted (true) for move (col0@row0 => row2).
TRACE Move score (-4), accepted (true) for move (col0@row0 => row3).
...
TRACE Move score (-3), accepted (true) for move (col1@row0 => row3).
...
TRACE Move score (-3), accepted (true) for move (col2@row0 => row3).
...
TRACE Move score (-4), accepted (true) for move (col3@row0 => row3).
DEBUG Step index (0), time spend (6), score (-3), new best score (-3), accepted move size (12) for picked step (col1@row0 => row3).
...
DEBUG Step index (1), time spend (10), score (-2), new best score (-2), accepted move size (12) for picked step (...).
...</pre>
</a><br>
- If there's a construction heuristic that doesn't crash: remove
it by:<br>
-- run only the construction heuristic config<br>
-- take the output solution as the new input solution<br>
-- remove the construction heuristic config<br>
<br>
- If it doesn't crash in step 0: remove non-crashing steps before
it<br>
-- run it just before the step it crashes and take the output
solution as the input solution<br>
-- verify that it now crashes in step 0 (*)<br>
<br>
- If it doesn't crash in the first move: remove non-crashing
move's before it<br>
-- Open DefaultDecider.decideNextStep(LocalSearchStepScope) and
add moveIterator.next().<br>
For example, if move 6 crashes:<br>
<br>
public void decideNextStep(LocalSearchStepScope
localSearchStepScope) {<br>
WorkingMemory workingMemory =
localSearchStepScope.getWorkingMemory();<br>
Iterator<Move> moveIterator =
selector.moveIterator(localSearchStepScope);<br>
// BEGIN<br>
moveIterator.next();<br>
moveIterator.next();<br>
moveIterator.next();<br>
moveIterator.next();<br>
moveIterator.next(); // 5 next()'s<br>
// END<br>
while (moveIterator.hasNext()) {<br>
Move move = moveIterator.next();<br>
...<br>
<br>
-- verify that it now crashes in move 0 (*)<br>
<br>
(*) If it doesn't crash, that means that an earlier step or move
helped cause this issue.<br>
Remove as many steps and moves as you can.<br>
This means that the final unit test will have multiple
fireAllRules():<br>
... do move 1 ...<br>
... fireAllRules<br>
... undo move 1 ...<br>
(... fireAllRules)<br>
... do move 2 ...<br>
... fireAllRules<br>
// Now the WM is corrupted<br>
<br>
<br>
- Now (and not sooner!), remove rules by commented out all the
rules in the DRL that doesn't stop the crashing<br>
- Remove all the problem facts and planning entities that doesn't
stop the crashing.<br>
- Now the problem should be small enough to rewrite it in a simple
unit test.</blockquote>
<br>
<br>
Op 15-05-12 06:39, Nurlan Rakhimzhanov schreef:
<blockquote
cite="mid:CAK02JMhcriqJjcAc44aYt5K41GV8KyuWw9KZ_Z4ahcPD96fcFA@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On 15 May 2012 00:30, Christopher Dolan <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:christopher.dolan@avid.com" target="_blank">christopher.dolan@avid.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
I may be way off track, but I saw score corruption like yours
in two cases:<br>
<br>
1) broken .equals()/.hashCode() method.<br>
I had a couple of model classes that accidentally looked at
mutable data in their .equals() and .hashCode() methods. When
these were applied as the cause of the constraint, the revert
action then failed to find the constraint because the removed
instance wasn't .equals() to the inserted instance. I solved
this by reverting to Object.equals() and Object.hashCode().<br>
</blockquote>
<div><br>
</div>
<div>I don't think that problem with .equals() or .hashCode()
methods, because I'm using
<b>apache EqualsBuilder</b> and <b>apache
HashCodeBuilder</b>, this is 1st, and 2nd my each
planning entity has al least unique <b>id</b>.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
2) broken variable assignment in aggregate predicates (<a
moz-do-not-send="true"
href="https://issues.jboss.org/browse/JBRULES-3482"
target="_blank">https://issues.jboss.org/browse/JBRULES-3482</a>)<br>
This is fixed in 5.4.0.Final.<br>
If your rules use collect() or accumulate() with a complicated
first argument to either, then Drools becomes confused about
which variable to assign the value to. In most cases, this
results in a ClassCastException. But in some cases where the
facts happened to be the same class, you ended up with the
wrong fact assigned as the cause of the constraint.</blockquote>
<div>yes, I'm using accumulate(), but not in this
rule(wxGroupChildClassesInSamePeriodWithDiffLessons) and I've
switched to 5.4.Final version, same problem....</div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="HOEnZb">
<div class="h5">
-----Original Message-----<br>
From: <a moz-do-not-send="true"
href="mailto:rules-users-bounces@lists.jboss.org">rules-users-bounces@lists.jboss.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:rules-users-bounces@lists.jboss.org">rules-users-bounces@lists.jboss.org</a>]
On Behalf Of Nurlan<br>
Sent: Friday, May 11, 2012 5:06 PM<br>
To: <a moz-do-not-send="true"
href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
Subject: [rules-users] Score curruption exception in
drools-planner-5.4.0.CR1<br>
<br>
Hi guys!<br>
I have some exception and I don't know why?<br>
My rule *someRuleId* has weight *1*<br>
2012-05-12 03:47:08,224 [main] DEBUG Step index (570),
time spend<br>
(115566), score (0hard/0soft), initialized planning entity<br>
(SomePlanningEntity [id=21, …]).<br>
2012-05-12 03:47:08,465 [main] DEBUG Step index (571),
time spend<br>
(115807), score (0hard/0soft), initialized planning entity<br>
(SomePlanningEntity [id=20, …]).<br>
java.lang.IllegalStateException: Score corruption: the
workingScore<br>
(-4hard/0soft) is not the uncorruptedScore (0hard/0soft):<br>
The workingMemory has 4 ConstraintOccurrence(s) in
excess:<br>
someRuleId/NEGATIVE_HARD:[SomePlanningEntity
[id=2482309, …],<br>
SomePlanningEntity [id=54, …]]=1<br>
someRuleId/NEGATIVE_HARD:[SomePlanningEntity
[id=2482309, …],<br>
SomePlanningEntity [id=57, …]]=1<br>
someRuleId/NEGATIVE_HARD:[SomePlanningEntity [id=57,
…],<br>
SomePlanningEntity [id=2482309, …]]=1<br>
someRuleId/NEGATIVE_HARD:[SomePlanningEntity [id=54,
…],<br>
SomePlanningEntity [id=2482309, …]]=1<br>
Check the score rules who created those
ConstraintOccurrences. Verify that<br>
each ConstraintOccurrence's causes and weight is correct.<br>
at<br>
org.drools.planner.core.score.director.AbstractScoreDirector.assertWorkingScore(AbstractScoreDirector.java:101)<br>
at<br>
org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.doMove(DefaultGreedyDecider.java:111)<br>
at<br>
org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.decideNextStep(DefaultGreedyDecider.java:78)<br>
at<br>
org.drools.planner.core.constructionheuristic.greedyFit.DefaultGreedyFitSolverPhase.solve(DefaultGreedyFitSolverPhase.java:63)<br>
at<br>
org.drools.planner.core.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:183)<br>
at<br>
org.drools.planner.core.solver.DefaultSolver.solve(DefaultSolver.java:151)<br>
…<br>
…<br>
<br>
<br>
--<br>
View this message in context: <a moz-do-not-send="true"
href="http://drools.46999.n3.nabble.com/Score-curruption-exception-in-drools-planner-5-4-0-CR1-tp3981199.html"
target="_blank">http://drools.46999.n3.nabble.com/Score-curruption-exception-in-drools-planner-5-4-0-CR1-tp3981199.html</a><br>
Sent from the Drools: User forum mailing list archive at
Nabble.com.<br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-users"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-users"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div style="font-size: 100%; margin: 0px; padding: 3px;
background-color: rgb(255, 255, 255); color: rgb(0, 0, 0);
font-family: 'Times New Roman';">
Regards, </div>
<div style="font-size: 100%; margin: 0px; padding: 3px;
background-color: rgb(255, 255, 255); color: rgb(0, 0, 0);
font-family: 'Times New Roman';">
Nurlan Rakhimzhanov</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
With kind regards,
Geoffrey De Smet</pre>
</body>
</html>