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

[Juergen none (JIRA)]

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: Feature Request
      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


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 (R5 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