[ https://issues.jboss.org/browse/DROOLS-915?page=com.atlassian.jira.plugin... ] Dmitry Toptygin commented on DROOLS-915: ---------------------------------------- Maybe this comment will help if anybody experiences this issue in the field. This defect, while not a true memory leak, has manifested itself for us this way: In the exaggerated rule example below, if AlarmFacts are rarely created (let's say one per day), and if ClearEvents come in very frequently (let's say once a second), then every day kSession would maintain references to unnecessary ClearEvents (up to 86000 of them). These ClearEvents are expired and not visible to the rules, kSession.getFactHandles() does not return them. But they are being kept in JVM memory by JoinNodeLeftTuple(s), via EventHactHandle. In order to release those ClearEvents, an artificial AlarmFact can be inserted periodically, which is not practical, or the rule can be rewritten - see "fixed rule example" at the end of the comment. --- begin bad rule example --- {code:java} package rules import org.example.memoryleak.events.ClearEvent import org.example.memoryleak.events.AlarmFact declare org.example.memoryleak.events.ClearEvent @role( event ) @timestamp( eventTimestamp ) @expires( 5s ) end rule "Delete alarm on clearEvent" when ClearEvent($devId: deviceId) $alarm: AlarmFact($devId == deviceId) then delete($alarm); end {code} --- end bad rule example --- --- begin fixed rule example --- {code:java} ... rule "Delete alarm on clearEvent" when $alarm: AlarmFact($devId: deviceId) ClearEvent(deviceId == $devId) then delete($alarm); end {code} --- end fixed rule example --- -- This message was sent by Atlassian JIRA (v6.4.11#64026)