I don't beleive there is anything in 4.0 that is going to cause such quick loss of permgen. Can you create a self contained example that illustrates this behaviour? So we can reproduce this?

Mark
s erel wrote:
We've tried to increase the permGen to 256mb. It did not help and the space run out really fast. Regarding MVEL, is turning code generation off something that can (or will) be done with a configuration parameter/factory method or do I need to track down all the places in the code? We did not experience such memory behavior with the previous version we used (3.06) when running the same tests.
Bugs in 3.06 (no longer present in 4M3) are forcing us to upgrade.
Is there another reason for such behaviour?
Should we wait for release candidate?

On 7/4/07, *Mark Proctor* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    increase your perm gen space,or use the MVEL dialect with code
    generation off.


    Mark
    s erel wrote:
    Hello,
During capacity tests we've received permGen OOM exception. The
    occupied space in the permGen area increases rapidly. Any opinions?


    On 7/3/07, *s erel* <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> wrote:

        In our project we are creating a StatefulRuleSession and
        saving it in a per-thread context (i.e. Each thread has it's
        own StatefulRuleSession):
ruleServiceProvider.getRuleRuntime().createRuleSession(contextName,
        properties, RuleRuntime.STATEFUL_SESSION_TYPE);
When a thread session ends, we are calling release on the
        previously created StatefulRuleSession.
Changing the following lines:
        public abstract class AbstractHashTable
        ...

            public Iterator iterator() {
        //        if ( this.iterator == null ) {
        //            this.iterator = new HashTableIterator( this );
        //        }
        //
        //        this.iterator.reset();
        //        return this.iterator;

                HashTableIterator iterator = new HashTableIterator(this);
                iterator.reset();

                return iterator;
            }

        Seems to solve the problem I've encountered. What's your opinion?

On 7/2/07, *Mark Proctor* <[EMAIL PROTECTED]
        <mailto:[EMAIL PROTECTED]>> wrote:

            a working memory should be single threaded, so not sure
            how this could be a race condition?

            Mark

            s erel wrote:
            I've done a little debugging. The code fails in the
            following segment:
public static class HashTableIterator
            ...
             while ( this.entry == null ) {
                                this.row++;
                                if ( this.row == this.length ) {
                                    return null;
                                }
                                this.entry = this.table[this.row];
            *// ---> index out of bounds exception*
                            }
            }
this.row has the same value as this.length despite the
            condition above it. Probably a race condition issue.

On 7/2/07, *Mark Proctor* <[EMAIL PROTECTED]
            <mailto:[EMAIL PROTECTED]>> wrote:

                Not really :(

                In your situation I tend to keep removing rules and
                data while still making sure the error happens, to
                get it down to a minimum. Please do try, as this
                isn't an error that should happen. Or alterntaively
                you can open drools-core and drools-compiler in
                eclipse and execuse and debug this yourself - in
                your situation this might best. you can put in a
                breakpoint to listen for that particular exception.

                Mark

                s erel wrote:
                It's hard for me to provide a self contained
                project. The drl is long and uses several business
                objects. It's the same drl as we've been using for
                306 minus the keyword changes.
                Is there anything else i can check or provide you
                in order to solve this matter.
Thanks On 7/1/07, *Mark Proctor* <[EMAIL PROTECTED]
                <mailto:[EMAIL PROTECTED]>> wrote:

                    Can you provide us a self contained project
                    which creates this error? Unless we can
                    recreate it, it will be very hard to track it
                    down. Please attach the project to a jira and
                    we'll make it a priority.

                    Mark
                    s erel wrote:
                    Hello,
I've just started integrating MR3 into my
                    project (I've previously used 3.06). The
                    drl compiles and everything seems fine, but
                    during
                    tests the following exception is thrown for
                    time to time:
java.lang.ArrayIndexOutOfBoundsException: 17
                     at
                    
org.drools.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:250)
                     at
                    
org.drools.reteoo.Rete$ObjectTypeConf.buildCache(Rete.java:434)
                     at
                    
org.drools.reteoo.Rete$ObjectTypeConf.getObjectTypeNodes(Rete.java:425)
                     at
                    org.drools.reteoo.Rete.assertObject(Rete.java:172)
                     at
                    
org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190)
                     at
                    
org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute
                    (ReteooWorkingMemory.java:163)
                     at
                    
org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1135)
                     at
                    
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:781)
                     at
                    
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:584)
                     at
                    
org.drools.jsr94.rules.StatefulRuleSessionImpl.addObject(StatefulRuleSessionImpl.java:162)
This only happens during high load tests.
                    Can anyone help me?
Thanks ------------------------------------------------------------------------

                    _______________________________________________
                    rules-users mailing list
                    [email protected] 
<mailto:[email protected]>
                    https://lists.jboss.org/mailman/listinfo/rules-users

                    _______________________________________________
                    rules-users mailing list
                    [email protected]
                    <mailto:[email protected]>
                    https://lists.jboss.org/mailman/listinfo/rules-users
                    <https://lists.jboss.org/mailman/listinfo/rules-users>


                
------------------------------------------------------------------------

                _______________________________________________
                rules-users mailing list
                [email protected] <mailto:[email protected]>
                https://lists.jboss.org/mailman/listinfo/rules-users


                _______________________________________________
                rules-users mailing list
                [email protected]
                <mailto:[email protected]>
                https://lists.jboss.org/mailman/listinfo/rules-users
                <https://lists.jboss.org/mailman/listinfo/rules-users>


            
------------------------------------------------------------------------

            _______________________________________________
            rules-users mailing list
            [email protected] <mailto:[email protected]>
            https://lists.jboss.org/mailman/listinfo/rules-users


            _______________________________________________
            rules-users mailing list
            [email protected]
            <mailto:[email protected]>
            https://lists.jboss.org/mailman/listinfo/rules-users
            <https://lists.jboss.org/mailman/listinfo/rules-users>



    ------------------------------------------------------------------------

    _______________________________________________
    rules-users mailing list
    [email protected] <mailto:[email protected]>
    https://lists.jboss.org/mailman/listinfo/rules-users


    _______________________________________________
    rules-users mailing list
    [email protected] <mailto:[email protected]>
    https://lists.jboss.org/mailman/listinfo/rules-users
    <https://lists.jboss.org/mailman/listinfo/rules-users>


------------------------------------------------------------------------

_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users

Reply via email to