[jboss-jira] [JBoss JIRA] (DROOLS-108) Rule score corruption using chaining

[Mario Fusco (JIRA)]

     [ https://issues.jboss.org/browse/DROOLS-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-108.
--------------------------------

    Resolution: Rejected



I finally have understood what's going on with that issue and now I believe there's no bug in rete nor in phreak, but the only wrong thing is the data model used in that test case. I am CCing Edson and Davide mainly because I believe that this test case underlines an interesting (and IMO useful) side effect of the lazy nature of phreak.

Lemme try to recap what I've found. First of all this is the rule used in that use case:

rule "standtime vs maxendtime"
    salience 20
    when
        not Plan(previousItemTaskorEquip == null)
        $table : Table(id != null, $tableName : name)
        $latestplan : Plan(previousItemTaskorEquip!= null,          
                     tableName == $tableName,
                     $maxend : getEquipEndTime(), $maxid : id, $maxstandtime : taskSeqStandTime
        )
       
        // NB working - selects such that latestplan is correct - strange thing not all the latestplans are used in heuristics - but are used in local search
         not Plan(previousItemTaskorEquip != null, tableName == $tableName,getEquipEndTime() > $maxend)
        // check all plans vs latestplan
          $plan : Plan(previousItemTaskorEquip != null, id != null, equip != null,
                     tableName == $tableName, getEquipEndTime() < $maxend, id != $maxid,
                     $equip : equip, $endtime: getEquipEndTime(), $standtime : taskSeqStandTime, $id : id)
        eval ($endtime + $standtime - $maxend < 0)
    then
        scoreHolder.addSoftConstraintMatch(kcontext, $endtime + $standtime - $maxend);
end

The problem is in the conditions under which the last eval gets evaluated and more in details in how that getEquipEndTime() method is defined in the Plan class.

In that test case 4 Plan get inserted named P6, P8, P10 and P12. The subsequent updates create a chain of these Plans and the result of that getEquipEndTime() method is a function of this chain.

What does happen in Rete is:

update P6: his ancestor in the chain is set to P10
update P8: his ancestor in the chain is set to P12

so in this moment there's the following situation

              | <- P8
head <- P12 <-|
              | <- P10 <-P6

The update of P8 triggers an assertion that is arrested by the eval node since its condition get evaluated as it follows:

$endtime (P8) = 7 (getAdjustedEquipStartTime) + 7 (taskSeqDuration) - 1 = 13
$standtime (P8) = 4
$maxend (P6) = 11 (getAdjustedEquipStartTime) + 4 (taskSeqDuration) - 1 = 14

$endtime + $standtime - $maxend < 0              <= false

Subsequently P10 is updated and its ancestor in the chain is changed from P12 to P8 generating the following situation:

head <- P12 <- P8 <- P10 <- P6

The reason why rete is failing should be evident now: together with P10 also P6 is indirectly changing, or at least it is changing the value it returns on that getEquipEndTime() method, but planner is not notifying drools with another update of P6.

What happens with phreak is that the evaluation is performed only after all the 3 updates. This means that the plan's chain used during the evaluation is the last one I showed above and in this case the evaluated condition returns true:

$endtime (P8) = 7 (getAdjustedEquipStartTime) + 7 (taskSeqDuration) - 1 = 13
$standtime (P8) = 4
$maxend (P6) = 18 (getAdjustedEquipStartTime) + 4 (taskSeqDuration) - 1 = 21

$endtime + $standtime - $maxend < 0              <= true
                
> Rule score corruption using chaining
> ------------------------------------
>
>                 Key: DROOLS-108
>                 URL: https://issues.jboss.org/browse/DROOLS-108
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Beta1
>         Environment: Linux Java 1.7 Eclipse Juno
>            Reporter: Paul T
>            Assignee: Mario Fusco
>         Attachments: OptaCrashExample-2.tar.gz, OptaCrashExample.zip
>
>
> Rule score corruption using chaining -  both 6.0.0.Beta1 and latest SnapShot

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira