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

[Geoffrey De Smet]

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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>

-- 
With kind regards,
Geoffrey De Smet