[rules-users] Streaming mode

[Richard Calmbach]

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 at 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 at 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 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/20120305/36c9a613/attachment.html