[jboss-jira] [JBoss JIRA] Commented: (JBRULES-1392) Rules behave incorrectly (randomly) in multi-threaded environment
Jan Boboli (JIRA)
jira-events at lists.jboss.org
Wed Feb 13 04:49:26 EST 2008
[ http://jira.jboss.com/jira/browse/JBRULES-1392?page=comments#action_12399317 ]
Jan Boboli commented on JBRULES-1392:
-------------------------------------
We still have some issues that appear in our project :
- strings are broken - i.e. if we have a string that represents date or a number, after running many rules the strings are broken - they consist random values. We are trying to reproduce the problem in a single project, but it's very difficult .
- we also observed, that some rules fire that didn't fire before and shouldn't fire, we are also trying to reproduce it in a single project.
Jan
> Rules behave incorrectly (randomly) in multi-threaded environment
> -----------------------------------------------------------------
>
> Key: JBRULES-1392
> URL: http://jira.jboss.com/jira/browse/JBRULES-1392
> Project: JBoss Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Reteoo
> Affects Versions: 4.0.3
> Reporter: Brian Stiles
> Assigned To: Edson Tirelli
> Priority: Blocker
> Fix For: 5.0.0-M1, 4.0.5
>
> Attachments: DroolsMVELFactoryProject.zip
>
>
> Rules behave seemingly indeterminately when sessions are created from the same RuleBase and executed in multiple threads. The problem is a bit difficult to reproduce. The following code demonstrates the behavior in my environment (single processor PowerBook), but not on every try. I've had up to 5 consecutive executions not exhibit the problem before the failure was exhibited, so you may need to run the class a number of times to see the problem. Also, I periodically get OutOfMemoryErrors when using the default heap size (64m). I've had better success with -Xmx256m. That, by the way, is suspiciously coincidental to the random nature of the incorrect rule firing problem.
> I've experienced this behavior in my application, and it manifests by rules firing from time to time that shouldn't have fired. I can't see a pattern to the rules that fire inappropriately, and there absolutely were not facts asserted that would support the firing of the rule.
> Synchronizing the calls to insert, fireAllRules, and dispose on the session object seems to get rid of the problem, giving further evidence to the guess that it's a multithreading bug.
> Please, please, please find a solution to this problem. This will be a serious scalability problem for my application. I'm more than happy to help however I can. I've stepped through Drools code before and found solutions, but I really don't know where to go with this one.
> Following is the code (self-contained class with main method) that I've used to demonstrate the problem.
> Thank you!
> --
> package sample;
> import java.io.StringReader;
> import java.util.ArrayList;
> import org.drools.RuleBase;
> import org.drools.RuleBaseConfiguration;
> import org.drools.RuleBaseFactory;
> import org.drools.StatefulSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.PackageBuilderConfiguration;
> public class MultithreadedRuleBaseProblem {
> public static void main(String[] args) throws Exception {
> final PackageBuilderConfiguration packageBuilderConfiguration =
> new PackageBuilderConfiguration();
> final PackageBuilder packageBuilder = new PackageBuilder(packageBuilderConfiguration);
> packageBuilder.addPackageFromDrl(new StringReader("\n"
> + "package sample\n"
> + "\n"
> + "import java.lang.Integer;\n"
> + "global java.util.ArrayList shouldFireList;\n"
> + "global java.util.ArrayList shouldNotFireList;\n"
> + "\n"
> + "rule should_fire\n"
> + " when\n"
> + " $e : Integer(intValue == -1)\n"
> + " $f : Integer(intValue > $e)\n"
> + " then \n"
> + " shouldFireList.add($f);\n"
> + "end \n"
> + "\n"
> + "rule should_not_fire\n"
> + " when\n"
> + " $f : String()\n"
> + " then \n"
> + " shouldNotFireList.add($f);\n"
> + "end \n"));
> final RuleBaseConfiguration ruleBaseConfiguration = new RuleBaseConfiguration();
> final RuleBase ruleBase = RuleBaseFactory.newRuleBase(ruleBaseConfiguration);
> ruleBase.addPackage(packageBuilder.getPackage());
> final Exception[] exception = {
> null
> };
> final Thread t[] = new Thread[50];
> for (int i = 0; i < t.length; i++) {
> final int count = i;
> t[i] = new Thread(new Runnable() {
> public void run() {
> try {
> System.out.println("Start " + count);
> final int iterations = count * 15 + 3000;
> final ArrayList shouldFireList = new ArrayList();
> final ArrayList shouldNotFireList = new ArrayList();
> final StatefulSession session2 = ruleBase.newStatefulSession();
> session2.setGlobal("shouldFireList", shouldFireList);
> session2.setGlobal("shouldNotFireList", shouldNotFireList);
> session2.insert(new Integer(- 1));
> for (int k = 0; k < iterations; k++) {
> session2.insert(new Integer(k));
> }
> session2.insert("foo");
> System.out.println("Fire " + count);
> session2.fireAllRules();
> session2.dispose();
> if (shouldFireList.size() != iterations) {
> System.out.println("Thread "
> + count
> + " shouldFireList.size(): expected "
> + iterations
> + " was "
> + shouldFireList.size()
> + "\n!!!!! Thread "
> + count
> + " rule didn't fire as many times as it should have!!!!!!!!!!!!!!!!!!");
> }
> } catch (Exception e) {
> e.printStackTrace();
> exception[0] = e;
> }
> System.out.println("Thread " + count + " done");
> }
> });
> t[i].start();
> }
> for (int i = 0; i < t.length; i++) {
> t[i].join();
> }
> System.out.println("done");
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list