[ http://jira.jboss.com/jira/browse/JBRULES-449?page=all ] Juergen none updated JBRULES-449: --------------------------------- Attachment: test_LogicalAssertionsAccumulatorPattern.drl from-unit-test-retracted-handles-as-justifiers-bug.jpg Took the time to create a unit-test. .drl attached, test-method as comment screenshot of invalid justifiedMap from unit-test Hope drools soon gets a grip on logical assertions -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-449?page=all ] Juergen none updated JBRULES-449: --------------------------------- Description: 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@15737ca, al FFF@b2d75c(A) (BBB@15737ca contributes to hash/equals of FFF@b2d75c) R5: BBB, CCC, FFF(A), not FFF(B) -> mod CCC (hashcodes changes, but all rules are still fulfilled as before), a FFF@b274de(B) R5 again (modify triggered): EEE, DDD, CCC -> a BBB@16d8ba (but equals(BBB@15737ca) is true), (+ my guess, object created and assert called but no listener info: al FFF@2aefe3(A) (equals FFF@b2d75c, backing its logical dependency) (BBB@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@b2d75c(A) and FFF@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 was: 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@15737ca, al FFF@b2d75c(A) (BBB@15737ca contributes to hash/equals of FFF@b2d75c) R5: BBB, CCC, FFF(A), not FFF(B) -> mod CCC (hashcodes changes, but all rules are still fulfilled as before), a FFF@b274de(B) R5 again (modify triggered): EEE, DDD, CCC -> a BBB@16d8ba (but equals(BBB@15737ca) is true), (+ my guess, object created and assert called but no listener info: al FFF@2aefe3(A) (equals FFF@b2d75c, backing its logical dependency) (BBB@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@b2d75c(A) and FFF@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

[ http://jira.jboss.com/jira/browse/JBRULES-449?page=comments#action_12342037 ] Juergen none commented on JBRULES-449: -------------------------------------- I think I have move infos. Problem outline: R1: A(b > 5) -> logical assert C A.b = 6 assert(A) --> C is asserted, and backed by logical dependency: R1, A A.b = 7 modify(A) --> C is backed a second time, but same rule/tuple: R1, A retract(A) --> only first logical dependency matching R1, A is removed, leaving the second one, whose handle on A becomes invalid I am not sure if its proper to add a second logical dependency for same rule/tuple: R1, A (even though the state of A is changed, from A.b == 6 to A.b == 7) or if the retract just should look for every possible logical dependency thats matched. I wonder on this case: A.b = 6 assert(A) modify(A) --> state of A is not changed, but modify called. Would second logical dependency be added, and if so, would it be proper? Unit-Test: If you look into justifiedMap immediately before FactHandle h is retracted, the CheeseEqual-Fact, that stays in memory has 2 Logical dependencies, BUT for the same activation and tuple. I think, the retract-algorithm does but check only for the first matching logical dependency, leaving the second one. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-449?page=all ] Edson Tirelli updated JBRULES-449: ---------------------------------- Issue Type: Bug (was: Feature Request) -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-449?page=all ] Mark Proctor updated JBRULES-449: --------------------------------- Fix Version/s: 3.1-m2 -- 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

[ 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. -- 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