For context: My observations were made with Drools 5.2.0 or earlier. Basically, rule consequences were not executed atomically, leading to bad interactions between multiple threads that were inserting events into different entry points. Due to my findings, I got cautious and just always synchronize on the session. I simply concluded that sessions are not thread-safe.

It is conceivable that later versions have fixes for the thread-safety issues I was seeing.

I cannot use any version of Drools later than 5.2.0 because the later versions (to the extent that I have tested them, including Drools 5.2.1) break about 46 of my unit tests. My application makes heavy use of Fusion, the complex event processing features. I reported the bugs in this thread (note: these are not thread safety bugs, as far as I can tell):

http://lists.jboss.org/pipermail/rules-users/2011-November/022826.html

which also contains a post where I link to the JIRA issues I created, following Edson's advice. The most critical bug here is https://issues.jboss.org/browse/JBRULES-3285. This bug prevents me from upgrading. Frankly, I'm surprised there aren't more reports of Fusion problems with post-5.2.0 versions.

Going back to thread-safety: As you can imagine, since the behavior I was seeing was due to a race condition, it was not always reproducible. Were the thread safety features you mention introduced post-5.2.0?

I know it is unsatisfying, but I cannot promise that I have the bandwidth to construct and verify an example that isolates the thread safety issue. I have found a workaround for that. The above issue with breaking unit tests is what I'm really concerned about - one rabbit hole at a time...

My intent with my post was to point out a possible reason for unexpected behavior in a multi-threaded setting and to describe a viable workaround. If this helps someone else overcome an obstacle, then there is value in it even if the underlying question of thread-safety remains unanswered. If the OP continues to see the same problem even after my suggested rewrite, he can rule out thread-safety issues, but for them, it may be worth a shot.

Thank you for your interest in resolving user issues. I'm sorry I can't be of more help this time, but as you can see from my JIRA history, I try to do my part. That's what an open source community is all about.

Thanks,
-Richard

2012/3/4 Mark Proctor <mproctor@codehaus.org>
If you have found an area where it is not thread safe, then please let us know so we can fix it. The example you have is redundant (possibly out of date), those areas are covered:

fireAllRules and fireUntilHalt both have an atomic boolean, to ensure they can never be called more than once at the same time.
if ( this.firing.compareAndSet( false, true ) ) {
           .....
}

Each method that undertakes a working memory operation; such as insert, update, retract creates a read lock on the KnowledgeBase and also a read/write lock on the session.
FactHandle insert(final Object object,
                                final boolean dynamic,
                                boolean logical,
                                final Rule rule,
                                final Activation activation) throws FactException {
            ....
            ....
            try {
                this.ruleBase.readLock();
                this.lock.lock();
                .....
            } finally {
                this.lock.unlock();
                this.ruleBase.readUnlock();

}


On 04/03/2012 04:36, Richard Calmbach wrote:
2012/3/2 Matteo Cusmai <cusmaimatteo@gmail.com>
i see that there are some other threads that insert new event and some others retract them.
How is the thread model?

Contrary to claims made on this mailing list, StatefulKnowledgeSession is not thread-safe (this may be due to bugs, but bottomline is: it's not thread-safe). In order to avoid errors due to multi-threading, don't use fireUntilHalt(), instead synchronize on the session and only call insert() and fireAllRules() while synchronized on the session:

    synchronized (session) {
        entryPoint.insert(event);
        session.fireAllRules();
    }

-Richard


_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users