[jboss-jira] [JBoss JIRA] Closed: (JBRULES-449) Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory

[Mark Proctor (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBRULES-449?page=all ]

Mark Proctor closed JBRULES-449.
--------------------------------

    Resolution: Done

I haven't heard this is a problem, so closing it off.

> Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-449
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-449
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions: 3.0.4
>         Environment: jdk 1.4.2_10
>            Reporter: Juergen none
>         Assigned To: Mark Proctor
>             Fix For: 3.1-m2
>
>         Attachments: from-unit-test-retracted-handles-as-justifiers-bug.jpg, retracted-handles-as-justifiers-bug.jpg, test_LogicalAssertionsAccumulatorPattern.drl
>
>
> Forget comlicated description, I leave it for history purposes, look at unit test attached.
> ============
> A rather complicated, intertwined set of rules leads to a logically asserted fact, that remains in working memory, even after its justifiers have been retracted.
> Sadly I have no unit-test, but I can outline the rules and execution sequence as reported by a listener (a ... assert, al ... assert logical, r ... retract)
> Its a buggy (BBB asserted twice) implementation of a accumulating set of rules I posted in the user list some time ago.
> FFF(A), FFF(B) are of same class but not equal, @... is systemHashCode, so different instances, but possible equal (as mentioned)
> classes without @ have only one instance in working memory
> a XXX
> R0: XXX -> al DDD
> a AAA (external assert)
> Sequence of rules fired
> R1: AAA -> al GGG
> R2: DDD, GGG -> al CCC
> R3: GGG -> al EEE
> R4: EEE, DDD, CCC -> a BBB at 15737ca, al FFF at b2d75c(A) (BBB at 15737ca contributes to hash/equals of FFF at b2d75c)
> R5: BBB, CCC, FFF(A), not FFF(B) -> mod CCC (hashcodes changes, but all rules are still fulfilled as before), a FFF at b274de(B)
> R5 again (modify triggered): EEE, DDD, CCC -> a BBB at 16d8ba (but equals(BBB at 15737ca) is true), (+ my guess, object created and assert called but no listener info: al FFF at 2aefe3(A) (equals FFF at b2d75c, backing its logical dependency) (BBB at 16d8ba contributes to Hash/equals))
> ---
> r AAA (external retract)
> -> (according to listener):
>   r AAA
>   r GGG
>   r EEE
>   r CCC
> breakpoint, screenshot --> justifier list is invalid, contains retracted handles
> PoolCondition would be DDD, the only valid handle in the (EEE, DDD, CCC) tuple
> r XXX (retract of XXX has no consequence, just the last handle, still valid in the screenshot, becomes invalid too)
> ->
>   r XXX
>   r DDD
> workingMemory.getObjects() lists FFF at b2d75c(A) and FFF at b274de(B)
> for Rulebase-properties:
> - RuleBaseConfiguration.PROPERTY_ASSERT_BEHAVIOR -> RuleBaseConfiguration.WM_BEHAVIOR_IDENTITY
> - empty
> Major lead could be that after commenting out "mod CCC",  FFF(A) is retracted (+ R5 not fired a second time)
> + problem with changed hashcode of CCC ?
> + problem with second instances of BBB and FFF(A) being asserted
> + FFF(B) being assert normally, not logically

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira