[rules-users] Help with MR3
s erel
erelsagi at gmail.com
Wed Jul 4 09:18:15 EDT 2007
Our server creates hundreds of stateful rule sessions concurrently. Each
created rule seesion is specific to a thread. We did not encounter
any memory problems with the previous version. As I've said, it's difficult
(actually, impossible) for me to provide you with a self contained example
since the drl is complicated and contains dozens of complex objects.
However, I am ready to provide you with any information that can help
us in that manner.
I've also mentioned in the earlier threads the concurrency problem I've
encountered with AbstractHashTable.
Can this has something to do with it?
On 7/4/07, Mark Proctor <mproctor at codehaus.org> wrote:
>
> 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 <mproctor at codehaus.org> 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 <erelsagi at gmail.com> 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 <mproctor at codehaus.org > 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 <mproctor at codehaus.org > 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 <mproctor at codehaus.org > 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 listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > ------------------------------
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > >
> > > > >
> > > > ------------------------------
> > > >
> > > > _______________________________________________
> > > > rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> > ------------------------------
> >
> > _______________________________________________
> > rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> ------------------------------
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070704/d5896194/attachment.html
More information about the rules-users
mailing list