Re: [rules-users] [Drools Planner] Hard constraint appears to be ignored

Op 26-02-12 19:47, Reinis schreef: > Hello, > >> 1) TRACE > It did actually crash! Good :) > java.lang.IllegalStateException: The presumedScore (0hard/-860soft) is corrupted because it is not the realScore (0hard/-858soft). It's not crashing on the hard constraint difference, but that probably means it doesn't get there yet. > Presumed workingMemory: > Score rule (reward Resource consolidation) has count (44) and weight total (44). > Real workingMemory: > Score rule (reward Resource consolidation) has count (46) and weight total (46). > > But the rule causing it looks "normal" to me: > rule "reward Resource consolidation" > when > $leftAssignment : Assignment($project : project, $leftResource : resource != null, $leftId : id) > $rightAssignment : Assignment(project == $project, resource == $leftResource, id != $leftId) > eval(new Duration(Math.abs($leftAssignment.getInterval().getStartMillis() - $rightAssignment.getInterval().getStartMillis())).getStandardDays() == 0) Looks good to me. What you could do is make a Assignment.getIntervalStartMillis() and Assignment( ..., $leftStartMillis : intervalStartMillis) and add that rightAssignment's startMillis should be> then leftAssignment's $leftStartMillis to avoid the Math.abs and double counting of this constraint. > then > insertLogical(new IntConstraintOccurrence("reward Resource consolidation", ConstraintType.POSITIVE > , 1, $leftAssignment, $rightAssignment)); > end > >> 2) drools version and planner version > drools-core-5.3.1.Final Can you try TRACE with drools-core, drools-compiler and knowledge-api 5.4.0.Beta2? There was a working memory corruption bug fixed in drools 5.4 over 5.3, not sure if it made 5.3.1. > drools-planner-core-5.3.1.Final (No need to upgrade planner itself at this time - as that will force you down the UpgradeRecipe.txt). > Thank you for the hints! Is the "eval" causing all this trouble? > > br > Reinis > > > On 02/26/2012 06:45 PM, Geoffrey De Smet wrote: > >> 1) If you haven't already, can you turn on<environmentMode>TRACE</...> >> and let it run a while (it will be much slower)? >> Report here if that crashes or not. >> >> 2) What drools version and what planner version are you using? >> >> Op 26-02-12 17:51, Reinis schreef: >>> Hello, it appears that hard constraint I have defined is being ignored >>> in some rare cases. Here's an example: >>> >>> This is what my application logs after getting best solution after >>> solver has returned from solve(): >>> >>> 2012-02-23 21:28:54,595 [main] INFO Project Project1 assignment >>> 563:[2012-02-27T13:00:00.000/2012-02-27T17:00:00.000] was assigned to John >>> >>> 2012-02-23 21:28:54,597 [main] INFO Project Project2 assignment >>> 508:[2012-02-27T13:00:00.000/2012-02-27T17:00:00.000] was assigned to John >>> >>> (The log says that John was assigned twice in same time period to two >>> different assignments (assignment 563 and assignment 508) >>> >>> Here short explanation of the relevant domain data >>> assignment.id = 563 >>> assignment.interval = 2012-02-27T13:00:00.000/2012-02-27T17:00:00.000 >>> assignment.project = Project1 >>> assignment.resource = John >>> >>> And this is rule that, to my opinion should've prohibited that two >>> assignments get assigned to the same resource: >>> >>> rule "only one assignment within interval for the same resource" >>> when >>> $leftAssignment : Assignment($leftId : id, $interval : >>> interval, resource != null, $resource : resource) >>> $rightAssignment : Assignment(interval == $interval, resource >>> == $resource, id != $leftId) >>> then >>> insertLogical(new IntConstraintOccurrence("only one assignment >>> within interval for the same resource", ConstraintType.NEGATIVE_HARD, 1, >>> $leftAssignment, $rightAssignment)); >>> end >>> >>> The score looks like this: >>> >>> 2012-02-23 21:28:54,594 [main] DEBUG The hard score is: 0 and the soft >>> score is: -532 >>> >>> So no hard constraints are broken according to planner. >>> >>> My question is not what is wrong with this particular example (unless it >>> is obvious for you), but if you can think of any anti-pattern that would >>> cause this behavior? >>> >>> What I already checked is: >>> - this happens really sporadically (most of the time the result is >>> CORRECT but in 1 from 5 runs I get this kind of error); >>> - I checked, re-checked and re-re-checked all the hashCode, compareTo, >>> solutionHashCode, solutionCompare, clone, ... methods - they appear to >>> be correct; >>> - moves are simple and I tried to keep them consistent with the way >>> moves in drools-planner examples are constructed; >>> >>> Would be great if you could give me a hint to what direction I should >>> look next. >>> >>> br >>> Reinis >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users >