Uploaded image for project: 'Drools'
  1. Drools
  2. DROOLS-1592

Deleted facts retained in memory, but removed after (de)serialization

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 7.1.0.Beta3
    • None
    • core engine
    • None
    • 2017 Week 22-23
    • Hide

      Run LeakDemo as JUnit test. Test written based on assumption that T1 facts retaining after their deletion is bug and their absense after (de)serialization is normal behavior.

      Show
      Run LeakDemo as JUnit test. Test written based on assumption that T1 facts retaining after their deletion is bug and their absense after (de)serialization is normal behavior.
    • Hide

      serialize-deserialize session when it's weight reaches critical value.

      Show
      serialize-deserialize session when it's weight reaches critical value.
    • NEW
    • NEW

      Given:
      two agenda groups: A1 and A2.
      Rule R1 in agenda group A1 and rule R2 in agenda group A2.
      R1 matches facts of type T1, deletes them and creates facts of type T2.
      R2 matches facts of type T2 and does soemthing with them (it doesn't matter, because issue happens even if R2 never fired).

      Scenario:

      • Create session, add R1 and R2 rules
      • add some facts of T1 type
      • set focus on A1 agenda group
      • invoke "fireAllRules" method
      • Invoke "getObjects" and assure that session contains only T2 facts
      • analyze objects in memory (by jmap + memory analyzing tool or just traversing references by reflection) and assure that T1 facts are still reachable via session object.
      • serialize session using marshaller and deserialize in again
      • analyze deserialized session and see that it doesn't contain T1 fact references anymore.

      Thoughts:
      I assumed that T1 references storing is feature, because they can be necessary in some cases (like reverse of their deletion due to logical inversion of truth - not sure, but maybe), but T1 deletion after (de)serialization points out the opposite.

              mfusco@redhat.com Mario Fusco
              kkolyan_jira Nikolay Plekhanov (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: