Thanks, we'll look at it tomorrow Davide On 07/15/2014 02:09 AM, Kent Anderson wrote: > https://github.com/droolsjbpm/drools/pull/358 > > Per your advice, this pull request sets up the memory leak, but it > cannot verify that it exists without diving into internal drools > structures. > > Please let me know what else we can do to facilitate fixing this issue. > > > On Jul 14, 2014, at 2:09 PM, Davide Sottara <dso...@gmail.com> wrote: > >> 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. >>> >>> >>> <Mail Attachment.png> >>> >>> >>> On Jul 13, 2014, at 7:31 PM, Mark Proctor <mproc...@codehaus.org >>> <mailto:mproc...@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.ander...@psware.com >>>> <mailto:kent.ander...@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.ander...@psware.com <mailto:kent.ander...@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.ander...@psware.com <mailto:kent.ander...@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@lists.jboss.org <mailto:rules-users@lists.jboss.org> >>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>> >>>>>> _______________________________________________ >>>>>> rules-users mailing list >>>>>> rules-users@lists.jboss.org <mailto:rules-users@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>> >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users@lists.jboss.org <mailto:rules-users@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users@lists.jboss.org <mailto:rules-users@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >> _______________________________________________ >> rules-users mailing list >> rules-users@lists.jboss.org <mailto:rules-users@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-users > > > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
