[rules-users] Workaround: EventFactHandle retained in memory after FactCount reaches 0 for temporal-based rule

[Davide Sottara]

I'd need to check, but if you can put together the basics of the test
case - the combination of rules and facts that causes the leak,
we'll add the checks to ensure it's solved. Mark should have given you
enough pointers to the style we use for test cases.
We really appreciate your collaboration, and since this is a critical
bug we'll fix it asap
Thanks!!
Davide

On 07/14/2014 08:33 PM, Kent Anderson wrote:
> Is there a reliable way to find an EventFactHandle instance buried
> within the TupleEntryQueue's and the PhreakPropagationContext's?
>
> The multiple containers of interface/impl's makes it nearly impossible
> to write a "good" test that can peak under the hood where this memory
> leak is being held.  If there is a recommended way to do it, I'd be
> happy to do so.
>
>
>
>
> On Jul 13, 2014, at 7:31 PM, Mark Proctor <mproctor at codehaus.org
> <mailto:mproctor at codehaus.org>> wrote:
>
>> Could you submit a unit test as a pull request?
>> http://docs.jboss.org/drools/release/5.5.0.Final/droolsjbpm-introduction-docs/html/gettingstarted.html
>>
>> Add it to here, and follow existing conventions:
>> https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepEspTest.java
>>
>> Mark
>> On 11 Jul 2014, at 20:38, Kent Anderson <kent.anderson at psware.com
>> <mailto:kent.anderson at psware.com>> wrote:
>>
>>> We have found a workaround that eliminates the leftover event (gone
>>> from Working Memory, but not from the JVM memory): 
>>>
>>> The rule "forget it ever happened" (seen below) causes the problem.
>>>  Re-writing it to remove the check for RAISE in the LHS eliminated
>>> the memory leak.  Of course, our application requires the check for
>>> RAISE, so it can be accomplished by manually querying working memory
>>> from the RHS.  It's ugly, but it resolved the issue.
>>>
>>> query existsRaise($id)
>>> $raise : MyEvent( eventState == EventState.RAISE, eventId == $id )
>>> end
>>>
>>> rule"process clear"
>>> no-loop
>>> when
>>> $clear : MyEvent(eventState == EventState.CLEAR, $clearId : eventId)
>>> then
>>> QueryResults results = kcontext.getKieRuntime().getQueryResults(
>>> "existsRaise", $clearId );
>>> if (results.size() == 0) { 
>>> System.out.println( "Forwarding CLEAR(" + $clearId + ")" ); 
>>> } else {
>>>         System.out.println("Forgetting RAISE/CLEAR(" + $clearId + ")");
>>>         for (QueryResultsRow row : results){
>>>         MyEvent raise = (MyEvent) row.get ("$raise");
>>>         delete(raise);
>>> }
>>> }
>>> delete($clear);
>>> end
>>>
>>> This appears to be a similar situation
>>> to https://issues.jboss.org/browse/DROOLS-498.
>>>
>>>
>>>
>>> On Jul 10, 2014, at 3:54 PM, Kent Anderson <kent.anderson at psware.com
>>> <mailto:kent.anderson at psware.com>> wrote:
>>>
>>>> Correction:  The original post did not include another rule that
>>>> exists in the stream.  The memory leak does not appear unless both
>>>> rules are active in the stream.
>>>>
>>>> declare MyEvent 
>>>>   @role(event) 
>>>>   @timestamp(timestamp) 
>>>> end 
>>>>
>>>> /* If a RAISE is buffered for N seconds, send it out */
>>>> rule"forward raise"
>>>> no-loop
>>>> duration(3s)
>>>> when
>>>> $raise : MyEvent(eventState == EventState.RAISE, $raiseId : eventId)
>>>> then
>>>> System.out.println("Forwarding RAISE(" + $raiseId + ")");
>>>> delete($raise);
>>>> end
>>>>
>>>> /* When CLEAR, and buffered, clear them both out */
>>>> rule"forget it ever happened"
>>>> no-loop
>>>> when
>>>> $clear : MyEvent(eventState == EventState.CLEAR, $clearId : eventId)
>>>> $raise : MyEvent(eventState == EventState.RAISE, eventId == $clearId)
>>>> then
>>>> System.out.println("Forgetting RAISE/CLEAR(" + $clearId + ")");
>>>> delete($clear);
>>>> delete($raise);
>>>> end
>>>>
>>>>
>>>> On Jul 10, 2014, at 2:50 PM, Kent Anderson
>>>> <kent.anderson at psware.com <mailto:kent.anderson at psware.com>> wrote:
>>>>
>>>>> The following rule produces a memory leak in Drools 6.1.0-SNAPSHOT:
>>>>>
>>>>> (Stream mode)
>>>>>
>>>>> declare MyEvent 
>>>>>   @role(event) 
>>>>>   @timestamp(timestamp) 
>>>>> end 
>>>>>
>>>>> /* If a RAISE is buffered for N seconds, send it out */
>>>>> rule"forward raise"
>>>>> no-loop
>>>>> duration(3s)
>>>>> when
>>>>> $raise : MyEvent(eventState == EventState.RAISE, $raiseId : eventId)
>>>>> then
>>>>> System.out.println("Forwarding RAISE(" + $raiseId + ")");
>>>>> delete($raise);
>>>>> end
>>>>>
>>>>>
>>>>> I see the rule fire as expected, printing out the message 3
>>>>> seconds after the event is added into the session.  While the
>>>>> event is waiting, I see a FactCount of 1 in the session.  After
>>>>> the rule fires, the fact count goes to 0.  However, using
>>>>> JVisualVm, querying the heap dump shows 1 instance of MyEvent,
>>>>> referenced by an EventFactHandle and several other Drools objects.
>>>>>
>>>>> Is this a bug, or is there a better way to write this rule so
>>>>> Drools' internals let go of the object after it is no longer a fact?
>>>>>
>>>>> <PastedGraphic-1.png>
>>>>>
>>>>> <PastedGraphic-2.png>
>>>>> _______________________________________________
>>>>> rules-users mailing list
>>>>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140714/b76de20a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 54629 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20140714/b76de20a/attachment-0001.png