Hi Wolfgang,<div><br></div><div>Thank you for your help. This sounds like a much better idea than what I have at the moment. </div><div><br></div><div>I&#39;ll have to read up on queries in Drools first, though, because I&#39;ve never used them before.</div>
<div><br><div class="gmail_quote">On Tue, May 29, 2012 at 12:21 PM, Wolfgang Laun <span dir="ltr">&lt;<a href="mailto:wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For this kind of clean-up (to get rid of events that have been around<br>
for 24h plus) you can insert a single event, let&#39;s call it EveryHour,<br>
and write a rule with a timer, to fire timer(int: 1h 1h). (If this is<br>
too coarse, use 15m 15 or whatever.) On the RHS, run a query to select<br>
all that you want to discard, and discard. The current time - 24h<br>
would have to be a parameter to the query.<br>
<br>
This should reduce the number of scheduled activations, at the cost of<br>
running the query; this depends on the number of Alarm events in the<br>
system.<br>
<br>
Other techniques I can think of might require some additional<br>
bookkeeping, so as to have all uncleared Alarms in some Collection.<br>
This could be tricky, depending on the number of state transitions,<br>
etc.<br>
<span class="HOEnZb"><font color="#888888"><br>
-W<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 29/05/2012, Werner Stoop &lt;<a href="mailto:wstoop@gmail.com">wstoop@gmail.com</a>&gt; wrote:<br>
&gt; Thanks Wolfgang,<br>
&gt;<br>
&gt; Yes, we do have a lot of events/hour, because it is a complex network we&#39;re<br>
&gt; monitoring. Our system has been running for some time, but the Drools rules<br>
&gt; engine is a new addition to attempt to manage some of the complexity.<br>
&gt;<br>
&gt; Perhaps I should clarify events and alarms: Our main system tracks alarms<br>
&gt; within the network, but each alarm may have several events, like an event<br>
&gt; when the alarm is first raised, an event when its status goes from major to<br>
&gt; critical and an event when the alarm is cleared. So the main entity in our<br>
&gt; rules is an Alarm, and whenever we get an event we insert a new Alarm into<br>
&gt; the knowledge base if we&#39;ve never seen the Alarm before, or update the<br>
&gt; Alarm if we have.<br>
&gt;<br>
&gt; We have one other rule that removes all Alarms whose status haven&#39;t changed<br>
&gt; for 24 hours, regardless of whether they have cleared or not. This rule&#39;s<br>
&gt; syntax is very similar to the one from my previous email. We specifically<br>
&gt; have this rule to try and keep the fact count in the rules engine<br>
&gt; manageable.<br>
&gt;<br>
&gt;   rule &quot;Old, Inactive Alarm?&quot;<br>
&gt;   timer(int: 30m 30m)<br>
&gt;   salience -10<br>
&gt;   when<br>
&gt; $a : Alarm(severity != &quot;cleared&quot;)<br>
&gt;   then<br>
&gt; double lastUpdate = minutesSince($a.getEventTime());<br>
&gt; if(lastUpdate &gt; 24 * 60) {<br>
&gt; retract($a);<br>
&gt; }<br>
&gt;   end<br>
&gt;<br>
&gt; So what you said would explain the memory usage. All Alarms end up in &quot;Old,<br>
&gt; Inactive Alarm?&quot;&#39;s queue waiting for 24 hours.<br>
&gt;<br>
&gt; I&#39;m going to disable this rule &quot;Old, Inactive Alarm?&quot; for the time being.<br>
&gt; Unfortunately the nature of the problem means that I&#39;ll have to monitor it<br>
&gt; for a day or two before I can draw any conclusions.<br>
&gt;<br>
&gt; It seems that the proper solution to this problem would be to get more<br>
&gt; memory.<br>
&gt;<br>
&gt; Thank you,<br>
&gt; Werner<br>
&gt;<br>
&gt; On Tue, May 29, 2012 at 9:35 AM, Wolfgang Laun<br>
&gt; &lt;<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>&gt;wrote:<br>
&gt;<br>
&gt;&gt; On 29/05/2012, Werner Stoop &lt;<a href="mailto:wstoop@gmail.com">wstoop@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; Hi, thank you for your response.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; We use Drools 5.3.1 through Maven. When I invoke Drools, for each event<br>
&gt;&gt; &gt; I<br>
&gt;&gt; &gt; receive I do the following:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;   ksession.insert(obj);<br>
&gt;&gt; &gt;   ksession.fireAllRules();<br>
&gt;&gt; &gt;<br>
&gt;&gt; This is OK.<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yes, we do use timers. In one case we want to remove alarms that have<br>
&gt;&gt; been<br>
&gt;&gt; &gt; cleared for more than an hour from the knowledgebase. We don&#39;t remove<br>
&gt;&gt; them<br>
&gt;&gt; &gt; immediately because some alarms clear briefly and then come back. The<br>
&gt;&gt; rule<br>
&gt;&gt; &gt; I&#39;ve written to handle this situation is the following:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; rule &quot;Old Cleared Alarm?&quot;<br>
&gt;&gt; &gt; timer(int: 10m 10m)<br>
&gt;&gt; &gt; salience -10<br>
&gt;&gt; &gt; when<br>
&gt;&gt; &gt; $a : Alarm(severity == &quot;cleared&quot;)<br>
&gt;&gt; &gt; then<br>
&gt;&gt; &gt; double lastUpdate = minutesSince($a.getEventTime());<br>
&gt;&gt; &gt; if(lastUpdate &gt; 60) {<br>
&gt;&gt; &gt; logger.debug(&quot;Alarm &quot; + $a.getAlarmId() + &quot; is old. Removing...&quot;);<br>
&gt;&gt; &gt; retract($a);<br>
&gt;&gt; &gt; }<br>
&gt;&gt; &gt; end<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Is there any other way to write this? I&#39;ve found that I can&#39;t put the<br>
&gt;&gt; &gt; minutesSince($a.getEventTime()) in the rule&#39;s when-clause.<br>
&gt;&gt;<br>
&gt;&gt; It&#39;s fine as you have it; it would not be evaluated correctly on the LHS.<br>
&gt;&gt;<br>
&gt;&gt; But considering 2000000 events, if they were all Alarm, you&#39;d have a<br>
&gt;&gt; rate of 17800 events/hour, and so you&#39;d have that many scheduled<br>
&gt;&gt; agenda items.<br>
&gt;&gt;<br>
&gt;&gt; What about the other timer rules for other Event types? Are there<br>
&gt;&gt; similar scenarios?<br>
&gt;&gt;<br>
&gt;&gt; -W<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thank you,<br>
&gt;&gt; &gt; Werner<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Tue, May 29, 2012 at 8:10 AM, Wolfgang Laun<br>
&gt;&gt; &gt; &lt;<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>&gt;wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; Just to make sure: How do you invoke the Engine? (I suppose you don&#39;t<br>
&gt;&gt; &gt;&gt; call with a limit for rule firings.)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Unless it&#39;s a bug (BTW: your Drools version is?), it&#39;s due to one or<br>
&gt;&gt; &gt;&gt; more of your rules.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Are you using timers? How?<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; A detailed investigation of the whereabouts of these<br>
&gt;&gt; &gt;&gt; ScheduledAgendaItem objects might be done by investigating (via the<br>
&gt;&gt; &gt;&gt; unstable API) the Agenda and its various components.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; -W<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On 28/05/2012, Werner Stoop &lt;<a href="mailto:wstoop@gmail.com">wstoop@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt; Hi,<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; We&#39;re using Drools with a StatefulKnowledgeSession to process events<br>
&gt;&gt; &gt;&gt; coming<br>
&gt;&gt; &gt;&gt; &gt; from equipment in our network. The system draws conclusions about<br>
&gt;&gt; &gt;&gt; &gt; the<br>
&gt;&gt; &gt;&gt; state<br>
&gt;&gt; &gt;&gt; &gt; of the equipment and writes those conclusions to a table in our<br>
&gt;&gt; &gt;&gt; &gt; database. All our rules work as we expected and the system produces<br>
&gt;&gt; the<br>
&gt;&gt; &gt;&gt; &gt; correct results.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; However, the memory usage of the JVM steadily goes up when the<br>
&gt;&gt; &gt;&gt; &gt; system<br>
&gt;&gt; &gt;&gt; runs<br>
&gt;&gt; &gt;&gt; &gt; for extended periods of time until we start getting<br>
&gt;&gt; &gt;&gt; &gt; OutOfMemoryExceptions<br>
&gt;&gt; &gt;&gt; &gt; and the server has to be restarted. This is in spite of the fact<br>
&gt;&gt; &gt;&gt; &gt; that<br>
&gt;&gt; &gt;&gt; &gt; the<br>
&gt;&gt; &gt;&gt; &gt; fact count reported by<br>
&gt;&gt; &gt;&gt; &gt; the StatefulKnowledgeSession.getFactCount() stays reasonably stable,<br>
&gt;&gt; &gt;&gt; &gt; with around 30 000 facts (give or take) at any point in time.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; I have run the Eclipse Memory Analyzer tool<br>
&gt;&gt; &gt;&gt; &gt; (<a href="http://www.eclipse.org/mat/" target="_blank">http://www.eclipse.org/mat/</a><br>
&gt;&gt; &gt;&gt; )<br>
&gt;&gt; &gt;&gt; &gt; against heap dumps from the JVM several times now, and every time it<br>
&gt;&gt; &gt;&gt; &gt; reports more and more instances<br>
&gt;&gt; &gt;&gt; &gt; of org.drools.common.ScheduledAgendaItem referenced from one<br>
&gt;&gt; &gt;&gt; &gt; instance<br>
&gt;&gt; &gt;&gt; &gt; of<br>
&gt;&gt; &gt;&gt; &gt; java.lang.Object[]<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; To be concrete, since this morning the uptime is more than 112 hours<br>
&gt;&gt; in<br>
&gt;&gt; &gt;&gt; &gt; total, during which the system has processed little over 2 000 000<br>
&gt;&gt; &gt;&gt; &gt; events<br>
&gt;&gt; &gt;&gt; &gt; from the network. It has 29 000 facts in the knowledge session, yet<br>
&gt;&gt; &gt;&gt; &gt; in<br>
&gt;&gt; &gt;&gt; the<br>
&gt;&gt; &gt;&gt; &gt; heap dump we see 829 632 instances of<br>
&gt;&gt; &gt;&gt; &gt; org.drools.common.ScheduledAgendaItem.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; What is the ScheduledAgendaItem for? Is there something wrong with<br>
&gt;&gt; &gt;&gt; &gt; my<br>
&gt;&gt; &gt;&gt; rules<br>
&gt;&gt; &gt;&gt; &gt; that causes this many instances to be held? Is there something I<br>
&gt;&gt; should<br>
&gt;&gt; &gt;&gt; do<br>
&gt;&gt; &gt;&gt; &gt; to release these instances or the Object[] holding on to them?<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; Thanks,<br>
&gt;&gt; &gt;&gt; &gt; Werner Stoop<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; rules-users mailing list<br>
&gt;&gt; &gt;&gt; <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
&gt;&gt; &gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; rules-users mailing list<br>
&gt;&gt; <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
&gt;&gt;<br>
&gt;<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br></div>