[rules-users] Rule compilation errors under heavy load

[Mark Proctor]

I think I've alread fixed this in trunk - when dealing with add/removing 
stuff I now do a block syncronisation on the pkgs instance. If that test 
is clean, we should add it to the list of integration tests, to track 
regressions.

Mark
Edson Tirelli wrote:
>
>    Dean
>
>    Thanks, we will investigate that asap.
>
>     []s
>     Edson
>
> 2007/7/12, Dean Jones <dean.m.jones at gmail.com 
> <mailto:dean.m.jones at gmail.com>>:
>
>     Hi Edson,
>
>     On 7/12/07, Edson Tirelli <tirelli at post.com
>     <mailto:tirelli at post.com>> wrote:
>     >
>     >    Is it possible for you to provide a test case capable of
>     reproducing the
>     > problem?
>     >
>     I've written a quick test case, which is attached. When
>     numberOfThreads==1,
>     everything compiles okay. When numberOfThreads==100, I get function
>     compilation errors and CompileExceptions from mvel. Clearly there is
>     nothing shared between these threads as a new test class is created
>     per thread. If you synchronise the calls to addPackage() and
>     getPackage() using the class monitor i.e.
>
>     synchronized (DroolsLoadTest.class) {
>     builder.addPackage(packageDescr);
>     builder.getPackage();
>     }
>
>     then the problems go away. Hope this helps.
>
>
>     >    At the same time, I would suggest you to not follow such
>     approach in your
>     > application. Compilation is an extremely heavy process and
>     should not be
>     > done for each request. The ideal approach is to pre-compile (for
>     instance,
>     > we have a contributed ant-task for that) and serialize your
>     rulebase to your
>     > database or filesystem, or at least, compile it only once and
>     cache it at
>     > runtime.
>     >
>     That's very sensible advice. Our situation is slightly different as
>     users are allowed to change the rules used by a running service,
>     so we
>     need to reflect any changes when a new request comes in. We are
>     planning to apply caching if performance is an issue, but we were
>     trying to assess performance of application under load when this
>     thread safety issue arose.
>
>     Thanks for your help,
>
>     Dean.
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
> -- 
>   Edson Tirelli
>   Software Engineer - JBoss Rules Core Developer
>   Office: +55 11 3529-6000
>   Mobile: +55 11 9287-5646
>   JBoss, a division of Red Hat @ www.jboss.com <http://www.jboss.com>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20070713/3b09b64d/attachment.html