Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
Meridian-2018.1.14, 25.2.1
-
Security Level: Default (Default Security Scheme)
-
Horizon 2020 - March 18th
Description
If a Drools engine has facts in working memory when reloadConfig is called, those facts are collected in a List<Object> object, and then re-inserted into the new session.
This results in the restored objects having a different class signature than the "same" ones in the new session, since they belong to a different classloader.
When this happens, Drools queries cannot find these facts and attempting to cast them to the appropriate class using their fact handles fails with a ClassCastException.
Steps to reproduce:
- Define a ruleset with a declared fact class, a query that searches for facts of that class, and a rule that executes that query and performs some operation on the matching facts.
- Insert one of those facts into working memory
- Call DroolsCorrelationEngine#reloadConfig(true) (optionally by sending a reloadDaemonConfig event)
- Insert another fact
- Trigger the rule to execute the query and perform operations on matching facts
Expected behavior:
The query should find all inserted facts and perform the desired operation on them
Actual behavior:
The fact inserted before reloadConfig was called is not found by the query, but the one inserted into the current session is found.
Drools offers marshall and unmarshall methods that use protobuf for serializing and deserializing working memory safely.
Test case attached.