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.<br>
<br>It is conceivable that later versions have fixes for the thread-safety issues I was seeing.<br><br>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):<br>
<br><a href="http://lists.jboss.org/pipermail/rules-users/2011-November/022826.html">http://lists.jboss.org/pipermail/rules-users/2011-November/022826.html</a><br><br>which also contains a post where I link to the JIRA issues I created, following Edson's advice. The most critical bug here is <a href="https://issues.jboss.org/browse/JBRULES-3285">https://issues.jboss.org/browse/JBRULES-3285</a>. This bug prevents me from upgrading. Frankly, I'm surprised there aren't more reports of Fusion problems with post-5.2.0 versions.<br>
<br>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?<br><br>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...<br>
<br>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.<br>
<br>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.<br>
<br>Thanks,<br>-Richard<br><br><div class="gmail_quote">2012/3/4 Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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:<br>
<br>
fireAllRules and fireUntilHalt both have an atomic boolean, to
ensure they can never be called more than once at the same time. <br>
if ( this.firing.compareAndSet( false, true ) ) {<br>
.....<br>
}<br>
<br>
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.<br>
FactHandle insert(final Object object,<br>
final boolean dynamic,<br>
boolean logical,<br>
final Rule rule,<br>
final Activation activation) throws
FactException {<br>
....<br>
....<br>
try {<br>
this.ruleBase.readLock();<br>
this.lock.lock();<br>
.....<br>
} finally {<br>
this.lock.unlock();<br>
this.ruleBase.readUnlock();<div><div></div><div class="h5"><br>
}<br>
<br>
<br>
On 04/03/2012 04:36, Richard Calmbach wrote:
</div></div><blockquote type="cite"><div><div></div><div class="h5">
<div class="gmail_quote">2012/3/2 Matteo Cusmai <span dir="ltr"><<a href="mailto:cusmaimatteo@gmail.com" target="_blank">cusmaimatteo@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i see that there are some other threads that insert new event
and some others retract them.<br>
How is the thread model?<br>
</blockquote>
</div>
<br>
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:<br>
<br>
synchronized (session) {<br>
entryPoint.insert(event);<br>
session.fireAllRules();<br>
}<br>
<br>
-Richard<br>
<br>
<fieldset></fieldset>
<br>
</div></div><div class="im"><pre>_______________________________________________
rules-users mailing list
<a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</div></blockquote>
<br>
</div>
<br>_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br></blockquote></div><br>