[rules-users] Multiple threading

[apache]

Hey,
I am trying to get multiple threads to insert events and run rules against the union of events inserted ( an as soon as they are inserted, a timer drools thread kicking of fireallrules() is not an option because that would introduce a delay ) and wanted some opinion on the following:

1. Stateless session is basically a wrapper around statefulsession and since per doc  statefulsession is not threadsafe is it  safe to assume 2 threads cannot insert and run fireallrules to compare against a union of objects inserted by multiple threads without some synchronication on event insertion and ESP fireallrulesrules ? ( would the answer still hold despite a drools-camel endpoint reading and storing exchanges from multiple threads ? )

2. If in the above point we simplify the case where the rule uses the "from" keyword and reads from a cache or a Db ( is reading from
A cache supported out of the box ? ) then will drools bhaviour will be bound by the thread which invokes fireallrules() ?
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[laune]

2012/2/10 Apache <[hidden email]>

Hey,
I am trying to get multiple threads to insert events and run rules against the union of events inserted ( an as soon as they are inserted, a timer drools thread kicking of fireallrules() is not an option because that would introduce a delay ) and wanted some opinion on the following:

1. Stateless session is basically a wrapper around statefulsession and since per doc  statefulsession is not threadsafe

From where did you learn this?

-W

 

is it  safe to assume 2 threads cannot insert and run fireallrules to compare against a union of objects inserted by multiple threads without some synchronication on event insertion and ESP fireallrulesrules ? ( would the answer still hold despite a drools-camel endpoint reading and storing exchanges from multiple threads ? )

2. If in the above point we simplify the case where the rule uses the "from" keyword and reads from a cache or a Db ( is reading from
A cache supported out of the box ? ) then will drools bhaviour will be bound by the thread which invokes fireallrules() ?
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[apache]

http://docs.jboss.org/jbpm/v5.2/javadocs/org/drools/KnowledgeBase.html#getStatefulKnowledgeSessions%28%29

http://docs.jboss.org/jbpm/v5.2/javadocs/org/drools/runtime/StatelessKnowledgeSession.html

Any replies ?

[Mark Proctor]

On 10/02/2012 03:36, Apache wrote:

Hey,
I am trying to get multiple threads to insert events and run rules against the union of events inserted ( an as soon as they are inserted, a timer drools thread kicking of fireallrules() is not an option because that would introduce a delay ) and wanted some opinion on the following:

1. Stateless session is basically a wrapper around statefulsession and since per doc  statefulsession is not threadsafe is it  safe to assume 2 threads cannot insert and run fireallrules to compare against a union of objects inserted by multiple threads without some synchronication on event insertion and ESP fireallrulesrules ? ( would the answer still hold despite a drools-camel endpoint reading and storing exchanges from multiple threads ? )

stateful sessions are thread safe, they just aren't multi-threaded. Each of the working memory actions hold a lock, so only one thread at a time can enter.

2. If in the above point we simplify the case where the rule uses the "from" keyword and reads from a cache or a Db ( is reading from
A cache supported out of the box ? ) then will drools bhaviour will be bound by the thread which invokes fireallrules() ? 

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[apache]

Mark
 the first link in my previous post says something contradictory to what you mentioned. I understand that one thread at a time can use the session just not 2 or more threads at the same time . Is that what you meant too ?

[laune]

There is just one interpretation of "thread-safe": All operations on an object are synchronized to avoid race conditions when two threads operate concurrently on an object.

Therefore it is, for instance, possible for two different threads to call, say, insert(): Locks ensure that one thread finishes the insertion before the other one is permitted to enter the critical section.

Notice, also, that a method such as fireUntilHalt() would be useless if the method would not guarantee proper synchronization while other threads (who else?) insert or modify or retract.

Mark's statement "Each of the working memory actions hold a lock, so only one thread at a time can enter." is somewhat misleading - there isn't one lock "held" by "each of the WM actions". There is one lock to be acquired and released by each action.

-W

On 10 February 2012 23:46, apache <[hidden email]> wrote:

Mark
 the first link in my previous post says something contradictory to what you
mentioned. I understand that one thread at a time can use the session just
not 2 or more threads at the same time . Is that what you meant too ?

--
View this message in context: http://drools.46999.n3.nabble.com/rules-users-Multiple-threading-tp3731592p3733915.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[Richard Calmbach]

Sorry to burst your bubble, but stateful knowledge sessions are most definitely not thread-safe. I have seen hard evidence to this effect in the form of incorrect execution results and log statements that clearly show that two threads were interacting in unexpected ways. In a nutshell: Rule consequences are not executed atomically. This can cause unexpected working memory changes (e.g., fact insertion) to happen on one thread in one rule consequence before another thread has finished executing another rule consequence. Note that I'm not talking about whatever threads Drools may be creating internally. I'm talking about application threads.

I have found synchronizing on the session object to be a reliable safeguard against unwanted thread interactions. Basically, this way all external fact insertions and calls to fireAllRules() are serialized.

If this is not supposed to be necessary (synchronizing on the session), then there is a thread-safety bug in Drools.

-Richard

2012/2/10 Mark Proctor <[hidden email]>

On 10/02/2012 03:36, Apache wrote:

Hey,
I am trying to get multiple threads to insert events and run rules against the union of events inserted ( an as soon as they are inserted, a timer drools thread kicking of fireallrules() is not an option because that would introduce a delay ) and wanted some opinion on the following:

1. Stateless session is basically a wrapper around statefulsession and since per doc  statefulsession is not threadsafe is it  safe to assume 2 threads cannot insert and run fireallrules to compare against a union of objects inserted by multiple threads without some synchronication on event insertion and ESP fireallrulesrules ? ( would the answer still hold despite a drools-camel endpoint reading and storing exchanges from multiple threads ? )

stateful sessions are thread safe, they just aren't multi-threaded. Each of the working memory actions hold a lock, so only one thread at a time can enter.

2. If in the above point we simplify the case where the rule uses the "from" keyword and reads from a cache or a Db ( is reading from
A cache supported out of the box ? ) then will drools bhaviour will be bound by the thread which invokes fireallrules() ? 

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[Mark Proctor]

On 14/02/2012 02:01, Richard Calmbach wrote:

Sorry to burst your bubble, but stateful knowledge sessions are most definitely not thread-safe. I have seen hard evidence to this effect in the form of incorrect execution results and log statements that clearly show that two threads were interacting in unexpected ways. In a nutshell: Rule consequences are not executed atomically. This can cause unexpected working memory changes (e.g., fact insertion) to happen on one thread in one rule consequence before another thread has finished executing another rule consequence. Note that I'm not talking about whatever threads Drools may be creating internally. I'm talking about application threads.

I have found synchronizing on the session object to be a reliable safeguard against unwanted thread interactions. Basically, this way all external fact insertions and calls to fireAllRules() are serialized.

If this is not supposed to be necessary (synchronizing on the session), then there is a thread-safety bug in Drools.

Over various releases we have tried to catch any areas that might bypass these locks. If you have found one, please provide us with a unit test and we'll fix.

Mark

-Richard

2012/2/10 Mark Proctor <[hidden email]>

On 10/02/2012 03:36, Apache wrote:

Hey,
I am trying to get multiple threads to insert events and run rules against the union of events inserted ( an as soon as they are inserted, a timer drools thread kicking of fireallrules() is not an option because that would introduce a delay ) and wanted some opinion on the following:

1. Stateless session is basically a wrapper around statefulsession and since per doc  statefulsession is not threadsafe is it  safe to assume 2 threads cannot insert and run fireallrules to compare against a union of objects inserted by multiple threads without some synchronication on event insertion and ESP fireallrulesrules ? ( would the answer still hold despite a drools-camel endpoint reading and storing exchanges from multiple threads ? )

stateful sessions are thread safe, they just aren't multi-threaded. Each of the working memory actions hold a lock, so only one thread at a time can enter.

2. If in the above point we simplify the case where the rule uses the "from" keyword and reads from a cache or a Db ( is reading from
A cache supported out of the box ? ) then will drools bhaviour will be bound by the thread which invokes fireallrules() ? 

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[Mark Proctor]

On 10/02/2012 22:46, apache wrote:

Mark
 the first link in my previous post says something contradictory to what you
mentioned. I understand that one thread at a time can use the session just
not 2 or more threads at the same time . Is that what you meant too ? 

I think you are referring to the javadoc of one particular method, let me know if there are others.

getStatefulKnowledgeSessions

Collection<StatefulKnowledgeSession> getStatefulKnowledgeSessions()

Return a collection of the StatefulKnowledgeSessions that exist in this KnowledgeBase. Be careful as sessions are not thread-safe and could be in use elsewhere.

That is incorrect and we'll get it corrected for next release.

Mark

--
View this message in context: http://drools.46999.n3.nabble.com/rules-users-Multiple-threading-tp3731592p3733915.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[Matt Shaw]

I concur with Richard.  I have several threads inserting and retracting facts and occasionally I get the following error whilst a rule is trying to execute.  Using Drools 5.4.0.Final.  I assume the object which caused the Rule to activate has been retracted by another thread before the consequence has had chance to use it.  I will try Richard suggestion of locking on the session object.

2012-08-15 13:10:38.148 RulesEngine [ERROR] Error initialising RulesEngine
Exception executing consequence for rule "Track north of 50 degrees" in com.thalesgroup.uk.smartsa.rulesengine: java.util.NoSuchElementException
        at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
        at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1283)
        at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1209)
        at org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1420)
        at org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:755)
        at org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:731)
        at org.drools.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:247)
        at com.thalesgroup.uk.smartsa.rulesengine.RulesEngine.<init>(RulesEngine.java:138)
        at com.thalesgroup.uk.smartsa.rulesengine.RulesEngine.main(RulesEngine.java:160)
Caused by: java.util.NoSuchElementException
        at java.util.LinkedList.remove(LinkedList.java:788)
        at java.util.LinkedList.removeFirst(LinkedList.java:134)
        at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:344)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:342)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:123)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:53)
        at com.thalesgroup.uk.smartsa.rulesengine.Rule_Track_north_of_50_degrees_5c6a78c0936b433eb591bf059baf2ea0.defaultConsequence(Rule_Track_north_of_50_degrees_5c6a78c0936b433eb591bf059baf2ea0.java:13)
        at com.thalesgroup.uk.smartsa.rulesengine.Rule_Track_north_of_50_degrees_5c6a78c0936b433eb591bf059baf2ea0DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
        at com.thalesgroup.uk.smartsa.rulesengine.Rule_Track_north_of_50_degrees_5c6a78c0936b433eb591bf059baf2ea0DefaultConsequenceInvoker.evaluate(Unknown Source)
        at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1273)
        ... 7 more

[Matt Shaw]

I concur with Richard.  I have several threads inserting and retracting facts and occasionally I get the following error whilst a rule is trying to execute.  Using Drools 5.4.0.Final.  I assume the object which caused the Rule to activate has been retracted by another thread before the consequence has had chance to use it.  I will try Richard suggestion of locking on the session object.

2012-08-15 13:10:38.148 RulesEngine [ERROR] Error initialising RulesEngine
Exception executing consequence for rule "Track north of 50 degrees" in com.thalesgroup.uk.smartsa.rulesengine: java.util.NoSuchElementException
        at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
        at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1283)
        at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1209)
        at org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1420)
        at org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:755)
        at org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:731)
        at org.drools.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:247)
        at com.thalesgroup.uk.smartsa.rulesengine.RulesEngine.<init>(RulesEngine.java:138)
        at com.thalesgroup.uk.smartsa.rulesengine.RulesEngine.main(RulesEngine.java:160)
Caused by: java.util.NoSuchElementException
        at java.util.LinkedList.remove(LinkedList.java:788)
        at java.util.LinkedList.removeFirst(LinkedList.java:134)
        at org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:344)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:342)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:123)
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:53)
        at com.thalesgroup.uk.smartsa.rulesengine.Rule_Track_north_of_50_degrees_5c6a78c0936b433eb591bf059baf2ea0.defaultConsequence(Rule_Track_north_of_50_degrees_5c6a78c0936b433eb591bf059baf2ea0.java:13)
        at com.thalesgroup.uk.smartsa.rulesengine.Rule_Track_north_of_50_degrees_5c6a78c0936b433eb591bf059baf2ea0DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
        at com.thalesgroup.uk.smartsa.rulesengine.Rule_Track_north_of_50_degrees_5c6a78c0936b433eb591bf059baf2ea0DefaultConsequenceInvoker.evaluate(Unknown Source)
        at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1273)
        ... 7 more