In my own designs I usually avoid static specially in JEE environments.

   In JEE environments I would create a pool of rulebases, either using mbeans, local JNDI or stateful session beans with a controlled number of instances that meets your needs. You need to fine tune to how heavy your concurrency and rules are but, just as an example, lets say you expect to have 50 concurrent users at any single instant, and then you find that the ideal rate for you is to have 1 rulebase for each 10 sessions. So, you need 5 rulebase instances.

   Once you have the pool, just have your stateless session beans that get a reference to one of the rulebases to create a new stateless session, execute there rules, and it is done.



2008/11/26 Kris Nuttycombe <>
On Wed, Nov 26, 2008 at 1:10 PM, Edson Tirelli <> wrote:

   Ok, lets start with a simple thing:   I can't see how 16 rules can create that many patterns. Are you sure you are not recompiling/recreating your rulebase multiple times? If not, then we may have a serious problem...


Thanks, Edson. I think that recompilation may be the problem; I'm creating the RuleBase in a @PostConstruct method in an ejb3 stateless session bean, and it looks like if multiple instances of the session bean are added to the pool the rule base is compiled multiple times. So, how to get around this problem? In another thread you said:

> Also, usage of statics is not always good, specially if you intent to run your application in a JEE environment.

so I presume that using a regular old singleton to share the RuleBase instance is not a good idea. Is there any approach you can suggest that will avoid using statics? This app is running under Glassfish.

Thanks for your help,



2008/11/26 Kris Nuttycombe <>
Hi, all,

I'm encountering significant problems with running out of memory when executing a small ruleset (only 16 rules, < 100 facts). I've run jmap on the process (which has previously spawned multiple stateless sessions in parallel) and it looks like Drools, and specifically the Eclipse jdt compiler, is seriously eating up memory. The code calling the is fairly simple; one of the initial facts is an accumulator that I refer to later:

        StatelessSession session = ruleBase.newStatelessSession();
        session.execute(initialFact, accumulator);


where ruleBase is a shared instance, and initialFact is a base fact that is expanded during rules processing. Is there something I should be doing to dispose the session after use to release the objects created by the drools compiler after use? I'm using a shared RuleBase, and I'm wondering whether it is somehow keeping references around. Are these sorts of object counts to be expected?



Instance Counts for All Classes (excluding platform)

104827 instances of class net.jxta.impl.document.LiteXMLElement$charRange
26806 instances of class net.jxta.impl.document.LiteXMLElement$tagRange
26733 instances of class org.eclipse.jdt.internal.compiler.lookup.MethodBinding
17366 instances of class [Lorg.eclipse.jdt.internal.compiler.lookup.TypeBinding;
12412 instances of class com.sun.enterprise.loader.EJBClassLoader$SentinelInputStream
10974 instances of class org.apache.commons.collections.SequencedHashMap$Entry
8683 instances of class org.eclipse.jdt.internal.compiler.codegen.CachedIndexEntry
7708 instances of class net.jxta.impl.document.LiteXMLElement
7450 instances of class org.hibernate.engine.CollectionKey
6836 instances of class org.netbeans.modules.schema2beans.AttrProp
6271 instances of class org.eclipse.jdt.internal.compiler.lookup.FieldBinding
5643 instances of class org.eclipse.jdt.internal.compiler.ast.MessageSend
4928 instances of class org.eclipse.jdt.internal.compiler.util.HashtableOfObject
4895 instances of class [Lorg.eclipse.jdt.internal.compiler.lookup.ReferenceBinding;
4546 instances of class org.eclipse.jdt.internal.compiler.lookup.LocalVariableBinding
4472 instances of class [Lorg.eclipse.jdt.internal.compiler.lookup.LocalVariableBinding;
4128 instances of class org.drools.rule.Pattern
3899 instances of class
3867 instances of class org.hibernate.engine.EntityEntry
3731 instances of class org.hibernate.collection.PersistentSet
3685 instances of class org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding
3360 instances of class org.drools.reteoo.SingleTupleSinkAdapter
3266 instances of class net.jxta.document.MimeMediaType
3264 instances of class org.drools.spi.PatternExtractor
3163 instances of class org.apache.axis.encoding.TypeMappingImpl$Pair
3137 instances of class org.hibernate.collection.PersistentBag
2881 instances of class org.eclipse.jdt.internal.compiler.lookup.MethodScope
2688 instances of class org.drools.base.ClassFieldExtractor

rules-users mailing list

rules-users mailing list

 Edson Tirelli
 JBoss Drools Core Development
 JBoss, a division of Red Hat @