If
- the equals/hashCode contract is followed (see Object#equals)
- even when considering that your output is suffering from https://issues.jboss.org/browse/JBRULES-3505 - it's unlogical that the rule behaves as it does

then it could be a "stateful memory corruption".
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.
Next, switch back and use this recipe to isolate that "stateful memory corruption" into a Drools Expert unit test, so we can fix it:
here's how I usually isolate such a bug to a small reproducable unit test:

- Turn on environmentMode TRACE so it crashes as fast as possible
- Turn on TRACE logging.
  http://docs.jboss.org/drools/release/5.4.0.Beta1/drools-planner-docs/html_single/index.html#d0e2450
So you see something like this:
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 (...).
...

- If there's a construction heuristic that doesn't crash: remove it by:
-- run only the construction heuristic config
-- take the output solution as the new input solution
-- remove the construction heuristic config

- If it doesn't crash in step 0: remove non-crashing steps before it
-- run it just before the step it crashes and take the output solution as the input solution
-- verify that it now crashes in step 0 (*)

- If it doesn't crash in the first move: remove non-crashing move's before it
-- Open DefaultDecider.decideNextStep(LocalSearchStepScope) and add moveIterator.next().
For example, if move 6 crashes:

    public void decideNextStep(LocalSearchStepScope localSearchStepScope) {
        WorkingMemory workingMemory = localSearchStepScope.getWorkingMemory();
        Iterator<Move> moveIterator = selector.moveIterator(localSearchStepScope);
        // BEGIN
        moveIterator.next();
        moveIterator.next();
        moveIterator.next();
        moveIterator.next();
        moveIterator.next(); // 5 next()'s
        // END
        while (moveIterator.hasNext()) {
            Move move = moveIterator.next();
        ...

-- verify that it now crashes in move 0 (*)

(*) If it doesn't crash, that means that an earlier step or move helped cause this issue.
Remove as many steps and moves as you can.
This means that the final unit test will have multiple fireAllRules():
  ... do move 1 ...
  ... fireAllRules
  ... undo move 1 ...
  (... fireAllRules)
  ... do move 2 ...
  ... fireAllRules
  // Now the WM is corrupted


- Now (and not sooner!), remove rules by commented out all the rules in the DRL that doesn't stop the crashing
- Remove all the problem facts and planning entities that doesn't stop the crashing.
- Now the problem should be small enough to rewrite it in a simple unit test.


Op 15-05-12 06:39, Nurlan Rakhimzhanov schreef:


On 15 May 2012 00:30, Christopher Dolan <christopher.dolan@avid.com> wrote:
I may be way off track, but I saw score corruption like yours in two cases:

1) broken .equals()/.hashCode() method.
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().

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>.
 
2) broken variable assignment in aggregate predicates (https://issues.jboss.org/browse/JBRULES-3482)
This is fixed in 5.4.0.Final.
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.
yes, I'm using accumulate(), but not in this rule(wxGroupChildClassesInSamePeriodWithDiffLessons) and I've switched to 5.4.Final version, same problem....
 
-----Original Message-----
From: rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Nurlan
Sent: Friday, May 11, 2012 5:06 PM
To: rules-users@lists.jboss.org
Subject: [rules-users] Score curruption exception in drools-planner-5.4.0.CR1

Hi guys!
I have some exception and I don't know why?
My rule *someRuleId* has weight *1*
2012-05-12 03:47:08,224 [main] DEBUG     Step index (570), time spend
(115566), score (0hard/0soft), initialized planning entity
(SomePlanningEntity [id=21, …]).
2012-05-12 03:47:08,465 [main] DEBUG     Step index (571), time spend
(115807), score (0hard/0soft), initialized planning entity
(SomePlanningEntity [id=20, …]).
java.lang.IllegalStateException: Score corruption: the workingScore
(-4hard/0soft) is not the uncorruptedScore (0hard/0soft):
 The workingMemory has 4 ConstraintOccurrence(s) in excess:
   someRuleId/NEGATIVE_HARD:[SomePlanningEntity [id=2482309, …],
SomePlanningEntity [id=54, …]]=1
   someRuleId/NEGATIVE_HARD:[SomePlanningEntity [id=2482309, …],
SomePlanningEntity [id=57, …]]=1
   someRuleId/NEGATIVE_HARD:[SomePlanningEntity [id=57, …],
SomePlanningEntity [id=2482309, …]]=1
   someRuleId/NEGATIVE_HARD:[SomePlanningEntity [id=54, …],
SomePlanningEntity [id=2482309, …]]=1
 Check the score rules who created those ConstraintOccurrences. Verify that
each ConstraintOccurrence's causes and weight is correct.
       at
org.drools.planner.core.score.director.AbstractScoreDirector.assertWorkingScore(AbstractScoreDirector.java:101)
       at
org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.doMove(DefaultGreedyDecider.java:111)
       at
org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.decideNextStep(DefaultGreedyDecider.java:78)
       at
org.drools.planner.core.constructionheuristic.greedyFit.DefaultGreedyFitSolverPhase.solve(DefaultGreedyFitSolverPhase.java:63)
       at
org.drools.planner.core.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:183)
       at
org.drools.planner.core.solver.DefaultSolver.solve(DefaultSolver.java:151)
       …
       …


--
View this message in context: http://drools.46999.n3.nabble.com/Score-curruption-exception-in-drools-planner-5-4-0-CR1-tp3981199.html
Sent from the Drools: User forum mailing list archive at Nabble.com.

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



--
Regards, 
Nurlan Rakhimzhanov


_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


-- 
With kind regards,
Geoffrey De Smet