Thanks, Amit, I'll give that approach a try.

A bit of additional information that seems like it might be related: I find that when I shut down the application server (Glassfish) in which this is running, or unload the EAR, I see a bunch of errors like this in the logs:

[#|2008-11-26T19:29:34.240+0000|WARNING|sun-appserver9.1|javax.enterprise.system.core.classloading|_ThreadID=18;_ThreadName=RMI TCP Connection(47)-;_RequestID=ac0e52f1-a56e-438a-acb3-a66a93c0e19
f;|Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace
        at com.sun.enterprise.loader.EJBClassLoader$SentinelInputStream.<init>(
        at com.sun.enterprise.loader.EJBClassLoader$InternalJarURLConnection.getInputStream(
        at java.lang.ClassLoader.getResourceAsStream(
        at com.sun.enterprise.loader.EJBClassLoader.getResourceAsStream(
        at org.drools.rule.PackageCompilationData$PackageClassLoader.getResourceAsStream(
        at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.isPackage(
        at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(
        at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(
        at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(
        at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(
        at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(
        at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(
        at org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(
        at org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(
        at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(
        at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypesFor(
        at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.methods(
        at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.faultInTypesForFieldsAndMethods(
        at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(
        at org.eclipse.jdt.internal.compiler.Compiler.process(
        at org.eclipse.jdt.internal.compiler.Compiler.compile(
        at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(
        at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(
        at org.drools.compiler.DialectRegistry.compileAll(
        at org.drools.compiler.PackageBuilder.addPackage(
        at org.drools.compiler.PackageBuilder.addPackageFromDrl(

Why is the stream of the compiled class not being closed? Could this be related?



On Wed, Nov 26, 2008 at 10:51 AM, Amit Mhatre <> wrote:
hi, I was facing similar issues some time back, though I was using a ruleflow and had >20000 fact objects evaluated daily. The problem I was facing was that the running time would get significantly slower day by day. The solution that fixed it was to use a statefulSession and call dispose() on the session once it is done. This made a single-run slower than before, but atleast fixed the problem of exponentially increasing the run-time after several days.

This might not necessarily be the ideal solution, so before you move to a StatefulSession and call session.dispose() after processing, you might want to try to increase the memory for the jvm, if is lower than the size of your facts, this might fix it.

It'd be useful to know if somebody has a better solution to Kris's problem.

- am

On Wed, Nov 26, 2008 at 9:35 AM, Kris Nuttycombe <> wrote:
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

I'm worst at what I do best, and for this gift I feel blessed
-- Kurt Cobain

rules-users mailing list