[rules-users] 14GB of NotNodeLeftTuples produced by one rule?

Wolfgang Laun wolfgang.laun at gmail.com
Mon Jan 7 05:22:07 EST 2013


The amount of memory required for 150K type "a" depends on the actual
distribution of this data w.r.t. fields id and user, and other
circumstances; it is not only the rule that is to blame.

There is one flaw, though: The rule would fire twice for a matching
pair of events of type "a". It's possible that you do want to have a
type "b" for both combinations of user and friendid, but you could
create both in a single rule, which should halve your memory
requirements. If there is no ordered attribute, use the timestamp to
restrict a pair to only one combination (hint: "after").

This will still generate a lot of network nodes.

Other ideas for reduction may have to take the entire application
scenario into account, e.g., can you retract events after they have
been paired, or how do you do inserts and calls to fireAllRules, etc.
Most importantly, however, is the actual frequency of id and user
values in relation to type "a" events.

-W



On 07/01/2013, Svenja Brunstein <svenja.brunstein at gmail.com> wrote:
> Hi all,
>
> we observe a strange behavior with one of our rules. After deployment
> and sending lots of events (~150,000 of type "a"), the server slows down
> rapidly until it runs out of memory.
> We checked with VisualVM which objects are filling the memory: In one
> moment there were almost 14GB of NotNodeLeftTuples (88,933,186 Instances)!
>
> This is our rule:
>
> rule "example"
> when
> $evt1:EventObject(type=='a', $id:data['id'], $user:user) from entry-point
> internalstream
> $evt2:EventObject(type=='a', data['id']==$id, user!=$user, $user2:user)
> from entry-point internalstream
> not(EventObject(type=='b', user==$user, data['friendid']==$user2) from
> entry-point internalstream)
> then
> EventObject evt = new EventObject();
> evt.setType('b');
> evt.setUser($evt1.getUser());
> evt.put('friendid', $evt2.getUser());
> entryPoints['internalstream'].insert(evt);
> end
>
> Is that behavior correct for such a size of event combinations when using a
> NOT in the rule?
>
> Thanks,
> Svenja
>


More information about the rules-users mailing list