Michael Neale | 3 Nov 2009 08:56
Picon
Gravatar

Re: [rules-dev] is this a bug? import function not supporting varargs?

I think there are issues with java5 syntax isms - which varargs is?

On Tue, Nov 3, 2009 at 2:17 PM, Jane James <jane6210 <at> yahoo.com> wrote:
> Hi guys,
>     I have a question regarding the import function feature in Drools
> 5.1.0M.
>
>     I am reading the Drools JBoss Rules 5.0 book Developer's guide by Michal
> Bali and tried one of the examples but somehow I couldn't get my rules work
> with the method that has varargs.
>
> Here's what I have (copied from page 123):
>
> public class ValidationHelper {
>     public static void error (RuleContext kcontext, Object... context) {
>         KnowledgeRuntime knowledgeRuntime = kcontext.getKnowledgeRuntime();
>         ValidationReport validationReport =
> (ValidationReport)knowledgeRuntime.getGlobal("validationReport");
>         ReportFactory reportFactory = (ReportFactory)
> knowledgeRuntime.getGlobal("reportFactory");
>
>         kcontext.insertLogical(reportFactory.createMessage(
>                 Message.Type.ERROR, kcontext.getRule().getName(),
>                 context));
>     }
> }
>
>
> then in my drools file (copied from page 42):
> i have
(Continue reading)

Michael Neale | 4 Nov 2009 02:44
Picon
Gravatar

Re: [rules-dev] is this a bug? import function not supporting varargs?

yes my point is the varargs thing probably will not work.

On Wed, Nov 4, 2009 at 4:59 AM, Jane James <jane6210 <at> yahoo.com> wrote:
>  public static void error (RuleContext kcontext, Object... context) {...}
>
> ===>Object... context
>
>
>
>
>
> ----- Original Message ----
> From: Michael Neale <michael.neale <at> gmail.com>
> To: Rules Dev List <rules-dev <at> lists.jboss.org>
> Sent: Mon, November 2, 2009 11:56:09 PM
> Subject: Re: [rules-dev] is this a bug? import function not supporting varargs?
>
> I think there are issues with java5 syntax isms - which varargs is?
>
> On Tue, Nov 3, 2009 at 2:17 PM, Jane James <jane6210 <at> yahoo.com> wrote:
>> Hi guys,
>>     I have a question regarding the import function feature in Drools
>> 5.1.0M.
>>
>>     I am reading the Drools JBoss Rules 5.0 book Developer's guide by Michal
>> Bali and tried one of the examples but somehow I couldn't get my rules work
>> with the method that has varargs.
>>
>> Here's what I have (copied from page 123):
>>
(Continue reading)

Edward Archibald | 4 Nov 2009 04:41

[rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?


I found the following deadlock which is, apparently, due to the concurrent execution
of a task for a 'delayed' rule with a concurrently executing application thread attempting to get access to
a 'global'.  Any recommendations for avoiding this type of deadlock besides not using rules with
'duration()' etc. which cause asynchronous execution with respect to my main application thread?

This problem is somewhat difficult to reproduce on demand but it does come up frequently when the 'delayed'
rule "DETECT MONITORING HAS STOPPED" is activated as a result of the trigger conditions.

===================================================================================

This thread, my application's EnterprisePolicyManager thread, is attempting to get access to a global,
policyMgr, and is waiting for
the 'lock.lock' on RetooStatefulSession

It owns the 'ReteooStatefulSession.actionQueue'
and is waiting for the ReteooStatefulSession.lock.lock

owns: java.util.LinkedList<E>  (id=207)
waited by: Thread [pool-3-thread-1] (Suspended)
owns: com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine  (id=208)
sun.misc.Unsafe.park(boolean, long) line: not available [native method] [local variables unavailable]
java.util.concurrent.locks.LockSupport.park() line: 118 [local variables unavailable]
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt() line: 681
[local variables
unavailable]
java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquireQueued(java.util.concurrent.locks.AbstractQueuedSynchronizer$Node,
int) line:
711
java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquire(int)
(Continue reading)

Greg Barton | 4 Nov 2009 06:43
Picon
Favicon

Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?

Well, I'm not sure how to avoid the deadlock without changing the drools codebase.  I was, however, able to
change the type of AbstractWorkingMemory.actionQueue to
java.util.concurrent.ConcurrentLinkedQueue and remove the synchronization over the queue with no
apparent ill effects. (Two tests failed for drools-core, but they failed whether the change was made or
not.)  Also I don't like the fact that the current code synchronizes on actionQueue, but then exposes it
outside the class through the getActionQueue() method, where access can be unsynchronized.  Changing it
to ConcurrentLinkedQueue makes it safe to expose externally. (Not to mention that the lock can be stolen
externally with the current code.)

diff attached.  If you can run drools compiled from trunk, apply the diff and see if it resolves the deadlock. 
If it does it's up to the drools devs as to whether the change should be made.  I'm just hacking about. :P

--- On Tue, 11/3/09, Edward Archibald <edward.archibald <at> continuent.com> wrote:

> From: Edward Archibald <edward.archibald <at> continuent.com>
> Subject: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?
> To: "rules-dev <at> lists.jboss.org" <rules-dev <at> lists.jboss.org>
> Date: Tuesday, November 3, 2009, 9:41 PM
> 
> I found the following deadlock which is, apparently, due to
> the concurrent execution
> of a task for a 'delayed' rule with a concurrently
> executing application thread attempting to get access to a
> 'global'.  Any recommendations for avoiding this type
> of deadlock besides not using rules with 'duration()' etc.
> which cause asynchronous execution with respect to my main
> application thread?
> 
> This problem is somewhat difficult to reproduce on demand
> but it does come up frequently when the 'delayed' rule
(Continue reading)

Michal Bali | 4 Nov 2009 07:35
Picon

Re: [rules-dev] is this a bug? import function not supporting varargs?

Hi Jane,

The varargs feature definitely works with 5.0.1. I haven't tried 5.1.0M.

You can download the working example from http://code.google.com/p/droolsbook/
Download the parent-1.0-examples.zip, extract it and see project validation in droolsBookParent/validation/src/main/resources/validation.drl. To test it you can run the unit test in droolsBookParent/validation/src/test/java/droolsbook/bank/service/impl/ValidationTest

You could also try to put the fuction inside the DRL itself as it is shown in validation.drl (code that is commented out)

BTW the 'Rules Dev List' is not for these type of questions. It is meant for core developers of the Drools platform.

Best regards,
Michal


On Wed, Nov 4, 2009 at 2:44 AM, Michael Neale <michael.neale <at> gmail.com> wrote:
yes my point is the varargs thing probably will not work.

On Wed, Nov 4, 2009 at 4:59 AM, Jane James <jane6210 <at> yahoo.com> wrote:
>  public static void error (RuleContext kcontext, Object... context) {...}
>
> ===>Object... context
>
>
>
>
>
> ----- Original Message ----
> From: Michael Neale <michael.neale <at> gmail.com>
> To: Rules Dev List <rules-dev <at> lists.jboss.org>
> Sent: Mon, November 2, 2009 11:56:09 PM
> Subject: Re: [rules-dev] is this a bug? import function not supporting varargs?
>
> I think there are issues with java5 syntax isms - which varargs is?
>
> On Tue, Nov 3, 2009 at 2:17 PM, Jane James <jane6210 <at> yahoo.com> wrote:
>> Hi guys,
>>     I have a question regarding the import function feature in Drools
>> 5.1.0M.
>>
>>     I am reading the Drools JBoss Rules 5.0 book Developer's guide by Michal
>> Bali and tried one of the examples but somehow I couldn't get my rules work
>> with the method that has varargs.
>>
>> Here's what I have (copied from page 123):
>>
>> public class ValidationHelper {
>>     public static void error (RuleContext kcontext, Object... context) {
>>         KnowledgeRuntime knowledgeRuntime = kcontext.getKnowledgeRuntime();
>>         ValidationReport validationReport =
>> (ValidationReport)knowledgeRuntime.getGlobal("validationReport");
>>         ReportFactory reportFactory = (ReportFactory)
>> knowledgeRuntime.getGlobal("reportFactory");
>>
>>         kcontext.insertLogical(reportFactory.createMessage(
>>                 Message.Type.ERROR, kcontext.getRule().getName(),
>>                 context));
>>     }
>> }
>>
>>
>> then in my drools file (copied from page 42):
>> i have
>>
>> import org.drools.runtime.rule.RuleContext;
>> import function ValidationHelper.error;
>> ...
>> rule test
>> when
>>   #condition
>> then
>>     error(drools)
>>
>>
>> but when I ran the test, I got error message:
>>
>> Exception in thread "main" org.drools.runtime.rule.ConsequenceException:
>> [Error: unable to resolve method:
>> ValidationHelper.error(org.drools.base.DefaultKnowledgeHelper)
>> [arglength=1]]
>>
>> If I remove the parameter Object... context, then everything worked. But I
>> do need the varargs here because I need my error message to be more
>> specific.
>>
>> Did anyone else encounter the same problems?
>>
>>
>> thanks!
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
>
>
> --
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Michael Neale | 4 Nov 2009 11:26
Picon
Gravatar

Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?

ha - was just musing with someone the other day who uses "duration"
anymore ;) I guess its still useful to people !

I would say that the "duration" codebase is probably fairly "old" - in
the sense that it probably pre-dates the availability of
j.u.concurrent (which was java 5 I think? ) - so please try out that
patch, if it works, we can probably pull it in (hoping Edson can take
a look).

On Wed, Nov 4, 2009 at 4:43 PM, Greg Barton <greg_barton <at> yahoo.com> wrote:
> Well, I'm not sure how to avoid the deadlock without changing the drools codebase.  I was, however, able
to change the type of AbstractWorkingMemory.actionQueue to
java.util.concurrent.ConcurrentLinkedQueue and remove the synchronization over the queue with no
apparent ill effects. (Two tests failed for drools-core, but they failed whether the change was made or
not.)  Also I don't like the fact that the current code synchronizes on actionQueue, but then exposes it
outside the class through the getActionQueue() method, where access can be unsynchronized.  Changing
it to ConcurrentLinkedQueue makes it safe to expose externally. (Not to mention that the lock can be
stolen externally with the current code.)
>
> diff attached.  If you can run drools compiled from trunk, apply the diff and see if it resolves the
deadlock.  If it does it's up to the drools devs as to whether the change should be made.  I'm just hacking
about. :P
>
> --- On Tue, 11/3/09, Edward Archibald <edward.archibald <at> continuent.com> wrote:
>
>> From: Edward Archibald <edward.archibald <at> continuent.com>
>> Subject: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?
>> To: "rules-dev <at> lists.jboss.org" <rules-dev <at> lists.jboss.org>
>> Date: Tuesday, November 3, 2009, 9:41 PM
>>
>> I found the following deadlock which is, apparently, due to
>> the concurrent execution
>> of a task for a 'delayed' rule with a concurrently
>> executing application thread attempting to get access to a
>> 'global'.  Any recommendations for avoiding this type
>> of deadlock besides not using rules with 'duration()' etc.
>> which cause asynchronous execution with respect to my main
>> application thread?
>>
>> This problem is somewhat difficult to reproduce on demand
>> but it does come up frequently when the 'delayed' rule
>> "DETECT MONITORING HAS STOPPED" is activated as a result of
>> the trigger conditions.
>>
>> ===================================================================================
>>
>> This thread, my application's EnterprisePolicyManager
>> thread, is attempting to get access to a global, policyMgr,
>> and is waiting for
>> the 'lock.lock' on RetooStatefulSession
>>
>> It owns the 'ReteooStatefulSession.actionQueue'
>> and is waiting for the ReteooStatefulSession.lock.lock
>>
>> owns: java.util.LinkedList<E>  (id=207)
>> waited by: Thread [pool-3-thread-1] (Suspended)
>> owns:
>> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine
>> (id=208)
>> sun.misc.Unsafe.park(boolean, long) line: not available
>> [native method] [local variables unavailable]
>> java.util.concurrent.locks.LockSupport.park() line: 118
>> [local variables unavailable]
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()
>> line: 681 [local variables unavailable]
>> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquireQueued(java.util.concurrent.locks.AbstractQueuedSynchronizer$Node,
>> int) line: 711
>> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquire(int)
>> line: 1041
>> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock()
>> line: 184 [local variables unavailable]
>> java.util.concurrent.locks.ReentrantLock.lock() line: 256
>> [local variables unavailable]
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).getGlobal(java.lang.String)
>> line: 587
>> com.continuent.tungsten.cluster.manager.policy.Rule_IF_IN_MAINTENANCE_MODE__CONSUME_ALL_NOTIFICATIONS_0Eval0Invoker.evaluate(org.drools.spi.Tuple,
>> org.drools.rule.Declaration[], org.drools.WorkingMemory,
>> java.lang.Object) line: not available
>> org.drools.rule.EvalCondition.isAllowed(org.drools.spi.Tuple,
>> org.drools.WorkingMemory, java.lang.Object) line: 117
>> org.drools.reteoo.EvalConditionNode.assertLeftTuple(org.drools.reteoo.LeftTuple,
>> org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory) line: 180
>> org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory,
>> org.drools.reteoo.LeftTuple) line: 117
>> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(org.drools.reteoo.LeftTuple,
>> org.drools.reteoo.RightTuple,
>> org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory, boolean) line: 28
>> org.drools.reteoo.JoinNode.assertObject(org.drools.common.InternalFactHandle,
>> org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory) line: 175
>> org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(org.drools.common.InternalFactHandle,
>> org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory) line: 42
>> org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(org.drools.reteoo.ObjectSinkPropagator,
>> org.drools.common.InternalWorkingMemory) line: 326
>> org.drools.reteoo.PropagationQueuingNode.propagateActions(org.drools.common.InternalWorkingMemory)
>> line: 221
>> org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(org.drools.common.InternalWorkingMemory)
>> line: 394
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
>> line: 1486
>> org.drools.common.NamedEntryPoint.insert(org.drools.common.InternalFactHandle,
>> java.lang.Object, org.drools.rule.Rule,
>> org.drools.spi.Activation) line: 158
>> org.drools.common.NamedEntryPoint.insert(java.lang.Object,
>> boolean, boolean, org.drools.rule.Rule,
>> org.drools.spi.Activation) line: 122
>> org.drools.common.NamedEntryPoint.insert(java.lang.Object)
>> line: 80
>> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine.insertFact(com.continuent.tungsten.commons.cluster.resource.notification.NotificationStreamID,
>> java.lang.Object, boolean) line: 162
>> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager.run()
>> line: 249
>> java.lang.Thread.run() line: 595
>>
>> The rule implicated in the above thread is:
>>
>> rule "IF IN MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS"
>> salience 999
>>   when
>>     notification : ClusterResourceNotification()
>> from entry-point "MONITORING"
>>     eval(policyMgr.getMode() ==
>> ClusterPolicyManagerMode.MAINTENANCE)
>>   then
>>      statistics.increment("IF IN
>> MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS");
>>     retract(notification);
>> end
>>
>>
>>
>> This other thread, apparently a scheduled thread for a rule
>> with a 10 second duration,
>> is attempting to insert a fact and owns the 'lock.lock' on
>> ReteooStatefulSession and
>> is waiting for the 'ReteooStatefulSession.actionQueue'.
>>
>> owns: org.drools.common.DefaultAgenda  (id=4046)
>> waiting for: java.util.LinkedList<E>  (id=207)
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
>> line: 1480
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(org.drools.common.InternalFactHandle,
>> java.lang.Object, org.drools.rule.Rule,
>> org.drools.spi.Activation, org.drools.reteoo.ObjectTypeConf)
>> line: 1051
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(java.lang.Object,
>> boolean, boolean, org.drools.rule.Rule,
>> org.drools.spi.Activation) line: 1001
>> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object,
>> boolean) line: 114
>> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object)
>> line: 108
>> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0.consequence(org.drools.spi.KnowledgeHelper,
>> com.continuent.tungsten.commons.cluster.resource.notification.DataServerNotification,
>> org.drools.FactHandle, java.lang.String,
>> org.drools.FactHandle,
>> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager,
>> org.apache.log4j.Logger) line: not available
>> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0ConsequenceInvoker.evaluate(org.drools.spi.KnowledgeHelper,
>> org.drools.WorkingMemory) line: not available
>> org.drools.common.DefaultAgenda.fireActivation(org.drools.spi.Activation)
>> line: 934
>> org.drools.common.Scheduler$DuractionJob.execute(org.drools.time.JobContext)
>> line: 70
>> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
>> line: 132
>> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
>> line: 110
>> java.util.concurrent.FutureTask$Sync.innerRun() line: 269
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(java.util.concurrent.FutureTask<V>).run()
>> line: 123
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask)
>> line: 65
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run()
>> line: 168
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(java.lang.Runnable)
>> line: 650
>> java.util.concurrent.ThreadPoolExecutor$Worker.run() line:
>> 675
>> java.lang.Thread.run() line: 595
>>
>> The rule for this task looks like:
>> rule "DETECT MONITORING HAS STOPPED"
>> duration(10s)
>> salience 1000
>>   when
>>     lastNotification :
>> DataServerNotification($resourceName : resourceName)
>>
>>   from entry-point "MONITORING"
>>
>>     not (DataServerNotification(resourceName ==
>> $resourceName,
>>
>>
>>    this after [10s] lastNotification)
>>
>>   from entry-point "MONITORING")
>>
>>     not (ManagerFailedAlarm(expired == false,
>>
>>    resourceName == $resourceName))
>>
>>     not (DataSource(name == $resourceName,
>>
>>    state == ResourceState.SHUNNED ||
>>
>>    state == ResourceState.FAILED))
>>
>>   then
>>     Object[] params = {$resourceName};
>>     if (policyMgr.getMode() !=
>> ClusterPolicyManagerMode.MAINTENANCE)
>>     {
>>
>> lastNotification.setResourceState(ResourceState.UNKNOWN);
>>       ManagerFailedAlarm alarm =
>>
>>         new
>> ManagerFailedAlarm(lastNotification, "rule detected monitor
>> stop",
>>
>>
>>    6, AlarmSeverity.FAULT);
>>       logger.info(alarm.toString());
>>       insert(alarm);
>>       update(lastNotification);
>>      }
>> end
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>

--

-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Edward Archibald | 5 Nov 2009 00:32

Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?

Hi Greg,

Thanks for the post.  I'll give this a shot.  Turns out that I can reproduce the issue often enough that I'll be
able to see if this simple change resolves it.

Regards,

Edward

________________________________________
From: rules-dev-bounces <at> lists.jboss.org [rules-dev-bounces <at> lists.jboss.org] On Behalf Of Greg
Barton [greg_barton <at> yahoo.com]
Sent: Tuesday, November 03, 2009 9:43 PM
To: Rules Dev List
Subject: Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?

Well, I'm not sure how to avoid the deadlock without changing the drools codebase.  I was, however, able to
change the type of AbstractWorkingMemory.actionQueue to
java.util.concurrent.ConcurrentLinkedQueue and remove the synchronization over the queue with no
apparent ill effects. (Two tests failed for drools-core, but they failed whether the change was made or
not.)  Also I don't like the fact that the current code synchronizes on actionQueue, but then exposes it
outside the class through the getActionQueue() method, where access can be unsynchronized.  Changing it
to ConcurrentLinkedQueue makes it safe to expose externally. (Not to mention that the lock can be stolen
externally with the current code.)

diff attached.  If you can run drools compiled from trunk, apply the diff and see if it resolves the deadlock. 
If it does it's up to the drools devs as to whether the change should be made.  I'm just hacking about. :P

--- On Tue, 11/3/09, Edward Archibald <edward.archibald <at> continuent.com> wrote:

> From: Edward Archibald <edward.archibald <at> continuent.com>
> Subject: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?
> To: "rules-dev <at> lists.jboss.org" <rules-dev <at> lists.jboss.org>
> Date: Tuesday, November 3, 2009, 9:41 PM
>
> I found the following deadlock which is, apparently, due to
> the concurrent execution
> of a task for a 'delayed' rule with a concurrently
> executing application thread attempting to get access to a
> 'global'.  Any recommendations for avoiding this type
> of deadlock besides not using rules with 'duration()' etc.
> which cause asynchronous execution with respect to my main
> application thread?
>
> This problem is somewhat difficult to reproduce on demand
> but it does come up frequently when the 'delayed' rule
> "DETECT MONITORING HAS STOPPED" is activated as a result of
> the trigger conditions.
>
> ===================================================================================
>
> This thread, my application's EnterprisePolicyManager
> thread, is attempting to get access to a global, policyMgr,
> and is waiting for
> the 'lock.lock' on RetooStatefulSession
>
> It owns the 'ReteooStatefulSession.actionQueue'
> and is waiting for the ReteooStatefulSession.lock.lock
>
> owns: java.util.LinkedList<E>  (id=207)
> waited by: Thread [pool-3-thread-1] (Suspended)
> owns:
> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine
> (id=208)
> sun.misc.Unsafe.park(boolean, long) line: not available
> [native method] [local variables unavailable]
> java.util.concurrent.locks.LockSupport.park() line: 118
> [local variables unavailable]
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()
> line: 681 [local variables unavailable]
> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquireQueued(java.util.concurrent.locks.AbstractQueuedSynchronizer$Node,
> int) line: 711
> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquire(int)
> line: 1041
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock()
> line: 184 [local variables unavailable]
> java.util.concurrent.locks.ReentrantLock.lock() line: 256
> [local variables unavailable]
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).getGlobal(java.lang.String)
> line: 587
> com.continuent.tungsten.cluster.manager.policy.Rule_IF_IN_MAINTENANCE_MODE__CONSUME_ALL_NOTIFICATIONS_0Eval0Invoker.evaluate(org.drools.spi.Tuple,
> org.drools.rule.Declaration[], org.drools.WorkingMemory,
> java.lang.Object) line: not available
> org.drools.rule.EvalCondition.isAllowed(org.drools.spi.Tuple,
> org.drools.WorkingMemory, java.lang.Object) line: 117
> org.drools.reteoo.EvalConditionNode.assertLeftTuple(org.drools.reteoo.LeftTuple,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory) line: 180
> org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory,
> org.drools.reteoo.LeftTuple) line: 117
> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(org.drools.reteoo.LeftTuple,
> org.drools.reteoo.RightTuple,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory, boolean) line: 28
> org.drools.reteoo.JoinNode.assertObject(org.drools.common.InternalFactHandle,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory) line: 175
> org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(org.drools.common.InternalFactHandle,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory) line: 42
> org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(org.drools.reteoo.ObjectSinkPropagator,
> org.drools.common.InternalWorkingMemory) line: 326
> org.drools.reteoo.PropagationQueuingNode.propagateActions(org.drools.common.InternalWorkingMemory)
> line: 221
> org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(org.drools.common.InternalWorkingMemory)
> line: 394
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
> line: 1486
> org.drools.common.NamedEntryPoint.insert(org.drools.common.InternalFactHandle,
> java.lang.Object, org.drools.rule.Rule,
> org.drools.spi.Activation) line: 158
> org.drools.common.NamedEntryPoint.insert(java.lang.Object,
> boolean, boolean, org.drools.rule.Rule,
> org.drools.spi.Activation) line: 122
> org.drools.common.NamedEntryPoint.insert(java.lang.Object)
> line: 80
> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine.insertFact(com.continuent.tungsten.commons.cluster.resource.notification.NotificationStreamID,
> java.lang.Object, boolean) line: 162
> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager.run()
> line: 249
> java.lang.Thread.run() line: 595
>
> The rule implicated in the above thread is:
>
> rule "IF IN MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS"
> salience 999
>   when
>     notification : ClusterResourceNotification()
> from entry-point "MONITORING"
>     eval(policyMgr.getMode() ==
> ClusterPolicyManagerMode.MAINTENANCE)
>   then
>      statistics.increment("IF IN
> MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS");
>     retract(notification);
> end
>
>
>
> This other thread, apparently a scheduled thread for a rule
> with a 10 second duration,
> is attempting to insert a fact and owns the 'lock.lock' on
> ReteooStatefulSession and
> is waiting for the 'ReteooStatefulSession.actionQueue'.
>
> owns: org.drools.common.DefaultAgenda  (id=4046)
> waiting for: java.util.LinkedList<E>  (id=207)
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
> line: 1480
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(org.drools.common.InternalFactHandle,
> java.lang.Object, org.drools.rule.Rule,
> org.drools.spi.Activation, org.drools.reteoo.ObjectTypeConf)
> line: 1051
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(java.lang.Object,
> boolean, boolean, org.drools.rule.Rule,
> org.drools.spi.Activation) line: 1001
> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object,
> boolean) line: 114
> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object)
> line: 108
> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0.consequence(org.drools.spi.KnowledgeHelper,
> com.continuent.tungsten.commons.cluster.resource.notification.DataServerNotification,
> org.drools.FactHandle, java.lang.String,
> org.drools.FactHandle,
> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager,
> org.apache.log4j.Logger) line: not available
> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0ConsequenceInvoker.evaluate(org.drools.spi.KnowledgeHelper,
> org.drools.WorkingMemory) line: not available
> org.drools.common.DefaultAgenda.fireActivation(org.drools.spi.Activation)
> line: 934
> org.drools.common.Scheduler$DuractionJob.execute(org.drools.time.JobContext)
> line: 70
> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
> line: 132
> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
> line: 110
> java.util.concurrent.FutureTask$Sync.innerRun() line: 269
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(java.util.concurrent.FutureTask<V>).run()
> line: 123
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask)
> line: 65
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run()
> line: 168
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(java.lang.Runnable)
> line: 650
> java.util.concurrent.ThreadPoolExecutor$Worker.run() line:
> 675
> java.lang.Thread.run() line: 595
>
> The rule for this task looks like:
> rule "DETECT MONITORING HAS STOPPED"
> duration(10s)
> salience 1000
>   when
>     lastNotification :
> DataServerNotification($resourceName : resourceName)
>
>   from entry-point "MONITORING"
>
>     not (DataServerNotification(resourceName ==
> $resourceName,
>
>
>    this after [10s] lastNotification)
>
>   from entry-point "MONITORING")
>
>     not (ManagerFailedAlarm(expired == false,
>
>    resourceName == $resourceName))
>
>     not (DataSource(name == $resourceName,
>
>    state == ResourceState.SHUNNED ||
>
>    state == ResourceState.FAILED))
>
>   then
>     Object[] params = {$resourceName};
>     if (policyMgr.getMode() !=
> ClusterPolicyManagerMode.MAINTENANCE)
>     {
>
> lastNotification.setResourceState(ResourceState.UNKNOWN);
>       ManagerFailedAlarm alarm =
>
>         new
> ManagerFailedAlarm(lastNotification, "rule detected monitor
> stop",
>
>
>    6, AlarmSeverity.FAULT);
>       logger.info(alarm.toString());
>       insert(alarm);
>       update(lastNotification);
>      }
> end
>
>
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Edson Tirelli | 5 Nov 2009 02:05
Picon
Gravatar

Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?


   Edward,

   Are you able to provide us with a test case? that would help us ensure we fix this and prevent future regressions.

   Thanks,
      Edson

2009/11/4 Edward Archibald <edward.archibald <at> continuent.com>
Hi Greg,

Thanks for the post.  I'll give this a shot.  Turns out that I can reproduce the issue often enough that I'll be able to see if this simple change resolves it.

Regards,

Edward

________________________________________
From: rules-dev-bounces <at> lists.jboss.org [rules-dev-bounces <at> lists.jboss.org] On Behalf Of Greg Barton [greg_barton <at> yahoo.com]
Sent: Tuesday, November 03, 2009 9:43 PM
To: Rules Dev List
Subject: Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?

Well, I'm not sure how to avoid the deadlock without changing the drools codebase.  I was, however, able to change the type of AbstractWorkingMemory.actionQueue to java.util.concurrent.ConcurrentLinkedQueue and remove the synchronization over the queue with no apparent ill effects. (Two tests failed for drools-core, but they failed whether the change was made or not.)  Also I don't like the fact that the current code synchronizes on actionQueue, but then exposes it outside the class through the getActionQueue() method, where access can be unsynchronized.  Changing it to ConcurrentLinkedQueue makes it safe to expose externally. (Not to mention that the lock can be stolen externally with the current code.)

diff attached.  If you can run drools compiled from trunk, apply the diff and see if it resolves the deadlock.  If it does it's up to the drools devs as to whether the change should be made.  I'm just hacking about. :P

--- On Tue, 11/3/09, Edward Archibald <edward.archibald <at> continuent.com> wrote:

> From: Edward Archibald <edward.archibald <at> continuent.com>
> Subject: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?
> To: "rules-dev <at> lists.jboss.org" <rules-dev <at> lists.jboss.org>
> Date: Tuesday, November 3, 2009, 9:41 PM
>
> I found the following deadlock which is, apparently, due to
> the concurrent execution
> of a task for a 'delayed' rule with a concurrently
> executing application thread attempting to get access to a
> 'global'.  Any recommendations for avoiding this type
> of deadlock besides not using rules with 'duration()' etc.
> which cause asynchronous execution with respect to my main
> application thread?
>
> This problem is somewhat difficult to reproduce on demand
> but it does come up frequently when the 'delayed' rule
> "DETECT MONITORING HAS STOPPED" is activated as a result of
> the trigger conditions.
>
> ===================================================================================
>
> This thread, my application's EnterprisePolicyManager
> thread, is attempting to get access to a global, policyMgr,
> and is waiting for
> the 'lock.lock' on RetooStatefulSession
>
> It owns the 'ReteooStatefulSession.actionQueue'
> and is waiting for the ReteooStatefulSession.lock.lock
>
> owns: java.util.LinkedList<E>  (id=207)
> waited by: Thread [pool-3-thread-1] (Suspended)
> owns:
> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine
> (id=208)
> sun.misc.Unsafe.park(boolean, long) line: not available
> [native method] [local variables unavailable]
> java.util.concurrent.locks.LockSupport.park() line: 118
> [local variables unavailable]
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()
> line: 681 [local variables unavailable]
> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquireQueued(java.util.concurrent.locks.AbstractQueuedSynchronizer$Node,
> int) line: 711
> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquire(int)
> line: 1041
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock()
> line: 184 [local variables unavailable]
> java.util.concurrent.locks.ReentrantLock.lock() line: 256
> [local variables unavailable]
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).getGlobal(java.lang.String)
> line: 587
> com.continuent.tungsten.cluster.manager.policy.Rule_IF_IN_MAINTENANCE_MODE__CONSUME_ALL_NOTIFICATIONS_0Eval0Invoker.evaluate(org.drools.spi.Tuple,
> org.drools.rule.Declaration[], org.drools.WorkingMemory,
> java.lang.Object) line: not available
> org.drools.rule.EvalCondition.isAllowed(org.drools.spi.Tuple,
> org.drools.WorkingMemory, java.lang.Object) line: 117
> org.drools.reteoo.EvalConditionNode.assertLeftTuple(org.drools.reteoo.LeftTuple,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory) line: 180
> org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory,
> org.drools.reteoo.LeftTuple) line: 117
> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(org.drools.reteoo.LeftTuple,
> org.drools.reteoo.RightTuple,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory, boolean) line: 28
> org.drools.reteoo.JoinNode.assertObject(org.drools.common.InternalFactHandle,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory) line: 175
> org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(org.drools.common.InternalFactHandle,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory) line: 42
> org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(org.drools.reteoo.ObjectSinkPropagator,
> org.drools.common.InternalWorkingMemory) line: 326
> org.drools.reteoo.PropagationQueuingNode.propagateActions(org.drools.common.InternalWorkingMemory)
> line: 221
> org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(org.drools.common.InternalWorkingMemory)
> line: 394
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
> line: 1486
> org.drools.common.NamedEntryPoint.insert(org.drools.common.InternalFactHandle,
> java.lang.Object, org.drools.rule.Rule,
> org.drools.spi.Activation) line: 158
> org.drools.common.NamedEntryPoint.insert(java.lang.Object,
> boolean, boolean, org.drools.rule.Rule,
> org.drools.spi.Activation) line: 122
> org.drools.common.NamedEntryPoint.insert(java.lang.Object)
> line: 80
> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine.insertFact(com.continuent.tungsten.commons.cluster.resource.notification.NotificationStreamID,
> java.lang.Object, boolean) line: 162
> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager.run()
> line: 249
> java.lang.Thread.run() line: 595
>
> The rule implicated in the above thread is:
>
> rule "IF IN MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS"
> salience 999
>   when
>     notification : ClusterResourceNotification()
> from entry-point "MONITORING"
>     eval(policyMgr.getMode() ==
> ClusterPolicyManagerMode.MAINTENANCE)
>   then
>      statistics.increment("IF IN
> MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS");
>     retract(notification);
> end
>
>
>
> This other thread, apparently a scheduled thread for a rule
> with a 10 second duration,
> is attempting to insert a fact and owns the 'lock.lock' on
> ReteooStatefulSession and
> is waiting for the 'ReteooStatefulSession.actionQueue'.
>
> owns: org.drools.common.DefaultAgenda  (id=4046)
> waiting for: java.util.LinkedList<E>  (id=207)
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
> line: 1480
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(org.drools.common.InternalFactHandle,
> java.lang.Object, org.drools.rule.Rule,
> org.drools.spi.Activation, org.drools.reteoo.ObjectTypeConf)
> line: 1051
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(java.lang.Object,
> boolean, boolean, org.drools.rule.Rule,
> org.drools.spi.Activation) line: 1001
> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object,
> boolean) line: 114
> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object)
> line: 108
> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0.consequence(org.drools.spi.KnowledgeHelper,
> com.continuent.tungsten.commons.cluster.resource.notification.DataServerNotification,
> org.drools.FactHandle, java.lang.String,
> org.drools.FactHandle,
> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager,
> org.apache.log4j.Logger) line: not available
> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0ConsequenceInvoker.evaluate(org.drools.spi.KnowledgeHelper,
> org.drools.WorkingMemory) line: not available
> org.drools.common.DefaultAgenda.fireActivation(org.drools.spi.Activation)
> line: 934
> org.drools.common.Scheduler$DuractionJob.execute(org.drools.time.JobContext)
> line: 70
> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
> line: 132
> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
> line: 110
> java.util.concurrent.FutureTask$Sync.innerRun() line: 269
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(java.util.concurrent.FutureTask<V>).run()
> line: 123
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask)
> line: 65
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run()
> line: 168
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(java.lang.Runnable)
> line: 650
> java.util.concurrent.ThreadPoolExecutor$Worker.run() line:
> 675
> java.lang.Thread.run() line: 595
>
> The rule for this task looks like:
> rule "DETECT MONITORING HAS STOPPED"
> duration(10s)
> salience 1000
>   when
>     lastNotification :
> DataServerNotification($resourceName : resourceName)
>
>   from entry-point "MONITORING"
>
>     not (DataServerNotification(resourceName ==
> $resourceName,
>
>
>    this after [10s] lastNotification)
>
>   from entry-point "MONITORING")
>
>     not (ManagerFailedAlarm(expired == false,
>
>    resourceName == $resourceName))
>
>     not (DataSource(name == $resourceName,
>
>    state == ResourceState.SHUNNED ||
>
>    state == ResourceState.FAILED))
>
>   then
>     Object[] params = {$resourceName};
>     if (policyMgr.getMode() !=
> ClusterPolicyManagerMode.MAINTENANCE)
>     {
>
> lastNotification.setResourceState(ResourceState.UNKNOWN);
>       ManagerFailedAlarm alarm =
>
>         new
> ManagerFailedAlarm(lastNotification, "rule detected monitor
> stop",
>
>
>    6, AlarmSeverity.FAULT);
>       logger.info(alarm.toString());
>       insert(alarm);
>       update(lastNotification);
>      }
> end
>
>
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



--
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat <at> www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Edward Archibald | 5 Nov 2009 02:06

Re: [rules-dev] Deadlock in the Drools core - suggested patch appears to resolve the issue

Hello Michael and Greg,

I have pulled the drools head, made the patch that Greg suggested (thanks Greg!) and deployed the
drools-core jar with my app.  Prior to this change, I was able to reproduce the deadlock - verified in the
debugger and in exactly the same place as my earlier post - roughly 50% of the time.  I have tried the same test
scenario, now, 10 times with no failures.

>From what I can tell, this problem will easily happen every time that I am already in the 'delayed
execution' code created by the rule with the 'duration()' qualifier and, at the same time, I get a new
'fact' and attempt to insert it. Knowing this, I can probably come up with a simpler test case. I'll give it a shot.

Thanks, again, to you both for the quick responses. 

Edward

-----Original Message-----
From: rules-dev-bounces <at> lists.jboss.org [mailto:rules-dev-bounces <at> lists.jboss.org] On Behalf Of
Michael Neale
Sent: Wednesday, November 04, 2009 2:26 AM
To: Rules Dev List
Subject: Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?

ha - was just musing with someone the other day who uses "duration"
anymore ;) I guess its still useful to people !

I would say that the "duration" codebase is probably fairly "old" - in
the sense that it probably pre-dates the availability of
j.u.concurrent (which was java 5 I think? ) - so please try out that
patch, if it works, we can probably pull it in (hoping Edson can take
a look).

On Wed, Nov 4, 2009 at 4:43 PM, Greg Barton <greg_barton <at> yahoo.com> wrote:
> Well, I'm not sure how to avoid the deadlock without changing the drools codebase.  I was, however, able
to change the type of AbstractWorkingMemory.actionQueue to
java.util.concurrent.ConcurrentLinkedQueue and remove the synchronization over the queue with no
apparent ill effects. (Two tests failed for drools-core, but they failed whether the change was made or
not.)  Also I don't like the fact that the current code synchronizes on actionQueue, but then exposes it
outside the class through the getActionQueue() method, where access can be unsynchronized.  Changing
it to ConcurrentLinkedQueue makes it safe to expose externally. (Not to mention that the lock can be
stolen externally with the current code.)
>
> diff attached.  If you can run drools compiled from trunk, apply the diff and see if it resolves the
deadlock.  If it does it's up to the drools devs as to whether the change should be made.  I'm just hacking
about. :P
>
> --- On Tue, 11/3/09, Edward Archibald <edward.archibald <at> continuent.com> wrote:
>
>> From: Edward Archibald <edward.archibald <at> continuent.com>
>> Subject: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?
>> To: "rules-dev <at> lists.jboss.org" <rules-dev <at> lists.jboss.org>
>> Date: Tuesday, November 3, 2009, 9:41 PM
>>
>> I found the following deadlock which is, apparently, due to
>> the concurrent execution
>> of a task for a 'delayed' rule with a concurrently
>> executing application thread attempting to get access to a
>> 'global'.  Any recommendations for avoiding this type
>> of deadlock besides not using rules with 'duration()' etc.
>> which cause asynchronous execution with respect to my main
>> application thread?
>>
>> This problem is somewhat difficult to reproduce on demand
>> but it does come up frequently when the 'delayed' rule
>> "DETECT MONITORING HAS STOPPED" is activated as a result of
>> the trigger conditions.
>>
>> ===================================================================================
>>
>> This thread, my application's EnterprisePolicyManager
>> thread, is attempting to get access to a global, policyMgr,
>> and is waiting for
>> the 'lock.lock' on RetooStatefulSession
>>
>> It owns the 'ReteooStatefulSession.actionQueue'
>> and is waiting for the ReteooStatefulSession.lock.lock
>>
>> owns: java.util.LinkedList<E>  (id=207)
>> waited by: Thread [pool-3-thread-1] (Suspended)
>> owns:
>> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine
>> (id=208)
>> sun.misc.Unsafe.park(boolean, long) line: not available
>> [native method] [local variables unavailable]
>> java.util.concurrent.locks.LockSupport.park() line: 118
>> [local variables unavailable]
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()
>> line: 681 [local variables unavailable]
>> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquireQueued(java.util.concurrent.locks.AbstractQueuedSynchronizer$Node,
>> int) line: 711
>> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquire(int)
>> line: 1041
>> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock()
>> line: 184 [local variables unavailable]
>> java.util.concurrent.locks.ReentrantLock.lock() line: 256
>> [local variables unavailable]
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).getGlobal(java.lang.String)
>> line: 587
>> com.continuent.tungsten.cluster.manager.policy.Rule_IF_IN_MAINTENANCE_MODE__CONSUME_ALL_NOTIFICATIONS_0Eval0Invoker.evaluate(org.drools.spi.Tuple,
>> org.drools.rule.Declaration[], org.drools.WorkingMemory,
>> java.lang.Object) line: not available
>> org.drools.rule.EvalCondition.isAllowed(org.drools.spi.Tuple,
>> org.drools.WorkingMemory, java.lang.Object) line: 117
>> org.drools.reteoo.EvalConditionNode.assertLeftTuple(org.drools.reteoo.LeftTuple,
>> org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory) line: 180
>> org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory,
>> org.drools.reteoo.LeftTuple) line: 117
>> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(org.drools.reteoo.LeftTuple,
>> org.drools.reteoo.RightTuple,
>> org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory, boolean) line: 28
>> org.drools.reteoo.JoinNode.assertObject(org.drools.common.InternalFactHandle,
>> org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory) line: 175
>> org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(org.drools.common.InternalFactHandle,
>> org.drools.spi.PropagationContext,
>> org.drools.common.InternalWorkingMemory) line: 42
>> org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(org.drools.reteoo.ObjectSinkPropagator,
>> org.drools.common.InternalWorkingMemory) line: 326
>> org.drools.reteoo.PropagationQueuingNode.propagateActions(org.drools.common.InternalWorkingMemory)
>> line: 221
>> org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(org.drools.common.InternalWorkingMemory)
>> line: 394
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
>> line: 1486
>> org.drools.common.NamedEntryPoint.insert(org.drools.common.InternalFactHandle,
>> java.lang.Object, org.drools.rule.Rule,
>> org.drools.spi.Activation) line: 158
>> org.drools.common.NamedEntryPoint.insert(java.lang.Object,
>> boolean, boolean, org.drools.rule.Rule,
>> org.drools.spi.Activation) line: 122
>> org.drools.common.NamedEntryPoint.insert(java.lang.Object)
>> line: 80
>> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine.insertFact(com.continuent.tungsten.commons.cluster.resource.notification.NotificationStreamID,
>> java.lang.Object, boolean) line: 162
>> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager.run()
>> line: 249
>> java.lang.Thread.run() line: 595
>>
>> The rule implicated in the above thread is:
>>
>> rule "IF IN MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS"
>> salience 999
>>   when
>>     notification : ClusterResourceNotification()
>> from entry-point "MONITORING"
>>     eval(policyMgr.getMode() ==
>> ClusterPolicyManagerMode.MAINTENANCE)
>>   then
>>      statistics.increment("IF IN
>> MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS");
>>     retract(notification);
>> end
>>
>>
>>
>> This other thread, apparently a scheduled thread for a rule
>> with a 10 second duration,
>> is attempting to insert a fact and owns the 'lock.lock' on
>> ReteooStatefulSession and
>> is waiting for the 'ReteooStatefulSession.actionQueue'.
>>
>> owns: org.drools.common.DefaultAgenda  (id=4046)
>> waiting for: java.util.LinkedList<E>  (id=207)
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
>> line: 1480
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(org.drools.common.InternalFactHandle,
>> java.lang.Object, org.drools.rule.Rule,
>> org.drools.spi.Activation, org.drools.reteoo.ObjectTypeConf)
>> line: 1051
>> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(java.lang.Object,
>> boolean, boolean, org.drools.rule.Rule,
>> org.drools.spi.Activation) line: 1001
>> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object,
>> boolean) line: 114
>> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object)
>> line: 108
>> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0.consequence(org.drools.spi.KnowledgeHelper,
>> com.continuent.tungsten.commons.cluster.resource.notification.DataServerNotification,
>> org.drools.FactHandle, java.lang.String,
>> org.drools.FactHandle,
>> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager,
>> org.apache.log4j.Logger) line: not available
>> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0ConsequenceInvoker.evaluate(org.drools.spi.KnowledgeHelper,
>> org.drools.WorkingMemory) line: not available
>> org.drools.common.DefaultAgenda.fireActivation(org.drools.spi.Activation)
>> line: 934
>> org.drools.common.Scheduler$DuractionJob.execute(org.drools.time.JobContext)
>> line: 70
>> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
>> line: 132
>> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
>> line: 110
>> java.util.concurrent.FutureTask$Sync.innerRun() line: 269
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(java.util.concurrent.FutureTask<V>).run()
>> line: 123
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask)
>> line: 65
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run()
>> line: 168
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(java.lang.Runnable)
>> line: 650
>> java.util.concurrent.ThreadPoolExecutor$Worker.run() line:
>> 675
>> java.lang.Thread.run() line: 595
>>
>> The rule for this task looks like:
>> rule "DETECT MONITORING HAS STOPPED"
>> duration(10s)
>> salience 1000
>>   when
>>     lastNotification :
>> DataServerNotification($resourceName : resourceName)
>>
>>   from entry-point "MONITORING"
>>
>>     not (DataServerNotification(resourceName ==
>> $resourceName,
>>
>>
>>    this after [10s] lastNotification)
>>
>>   from entry-point "MONITORING")
>>
>>     not (ManagerFailedAlarm(expired == false,
>>
>>    resourceName == $resourceName))
>>
>>     not (DataSource(name == $resourceName,
>>
>>    state == ResourceState.SHUNNED ||
>>
>>    state == ResourceState.FAILED))
>>
>>   then
>>     Object[] params = {$resourceName};
>>     if (policyMgr.getMode() !=
>> ClusterPolicyManagerMode.MAINTENANCE)
>>     {
>>
>> lastNotification.setResourceState(ResourceState.UNKNOWN);
>>       ManagerFailedAlarm alarm =
>>
>>         new
>> ManagerFailedAlarm(lastNotification, "rule detected monitor
>> stop",
>>
>>
>>    6, AlarmSeverity.FAULT);
>>       logger.info(alarm.toString());
>>       insert(alarm);
>>       update(lastNotification);
>>      }
>> end
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev <at> lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>

--

-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Edward Archibald | 5 Nov 2009 02:07

Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?

Hi Edson,

 

Our emails just crossed paths.  Yes, I believe that I can reproduce this.  I’ll try to turn this around quickly.

 

Ed

 

 

From: rules-dev-bounces <at> lists.jboss.org [mailto:rules-dev-bounces <at> lists.jboss.org] On Behalf Of Edson Tirelli
Sent: Wednesday, November 04, 2009 5:06 PM
To: Rules Dev List
Subject: Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?

 


   Edward,

   Are you able to provide us with a test case? that would help us ensure we fix this and prevent future regressions.

   Thanks,
      Edson

2009/11/4 Edward Archibald <edward.archibald <at> continuent.com>

Hi Greg,

Thanks for the post.  I'll give this a shot.  Turns out that I can reproduce the issue often enough that I'll be able to see if this simple change resolves it.

Regards,

Edward

________________________________________
From: rules-dev-bounces <at> lists.jboss.org [rules-dev-bounces <at> lists.jboss.org] On Behalf Of Greg Barton [greg_barton <at> yahoo.com]
Sent: Tuesday, November 03, 2009 9:43 PM
To: Rules Dev List
Subject: Re: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?


Well, I'm not sure how to avoid the deadlock without changing the drools codebase.  I was, however, able to change the type of AbstractWorkingMemory.actionQueue to java.util.concurrent.ConcurrentLinkedQueue and remove the synchronization over the queue with no apparent ill effects. (Two tests failed for drools-core, but they failed whether the change was made or not.)  Also I don't like the fact that the current code synchronizes on actionQueue, but then exposes it outside the class through the getActionQueue() method, where access can be unsynchronized.  Changing it to ConcurrentLinkedQueue makes it safe to expose externally. (Not to mention that the lock can be stolen externally with the current code.)

diff attached.  If you can run drools compiled from trunk, apply the diff and see if it resolves the deadlock.  If it does it's up to the drools devs as to whether the change should be made.  I'm just hacking about. :P

--- On Tue, 11/3/09, Edward Archibald <edward.archibald <at> continuent.com> wrote:

> From: Edward Archibald <edward.archibald <at> continuent.com>
> Subject: [rules-dev] Deadlock in the Drools core - Drools 5.0 - any suggestions for resolution?
> To: "rules-dev <at> lists.jboss.org" <rules-dev <at> lists.jboss.org>
> Date: Tuesday, November 3, 2009, 9:41 PM
>
> I found the following deadlock which is, apparently, due to
> the concurrent execution
> of a task for a 'delayed' rule with a concurrently
> executing application thread attempting to get access to a
> 'global'.  Any recommendations for avoiding this type
> of deadlock besides not using rules with 'duration()' etc.
> which cause asynchronous execution with respect to my main
> application thread?
>
> This problem is somewhat difficult to reproduce on demand
> but it does come up frequently when the 'delayed' rule
> "DETECT MONITORING HAS STOPPED" is activated as a result of
> the trigger conditions.
>
> ===================================================================================
>
> This thread, my application's EnterprisePolicyManager
> thread, is attempting to get access to a global, policyMgr,
> and is waiting for
> the 'lock.lock' on RetooStatefulSession
>
> It owns the 'ReteooStatefulSession.actionQueue'
> and is waiting for the ReteooStatefulSession.lock.lock
>
> owns: java.util.LinkedList<E>  (id=207)
> waited by: Thread [pool-3-thread-1] (Suspended)
> owns:
> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine
> (id=208)
> sun.misc.Unsafe.park(boolean, long) line: not available
> [native method] [local variables unavailable]
> java.util.concurrent.locks.LockSupport.park() line: 118
> [local variables unavailable]
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt()
> line: 681 [local variables unavailable]
> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquireQueued(java.util.concurrent.locks.AbstractQueuedSynchronizer$Node,
> int) line: 711
> java.util.concurrent.locks.ReentrantLock$NonfairSync(java.util.concurrent.locks.AbstractQueuedSynchronizer).acquire(int)
> line: 1041
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock()
> line: 184 [local variables unavailable]
> java.util.concurrent.locks.ReentrantLock.lock() line: 256
> [local variables unavailable]
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).getGlobal(java.lang.String)
> line: 587
> com.continuent.tungsten.cluster.manager.policy.Rule_IF_IN_MAINTENANCE_MODE__CONSUME_ALL_NOTIFICATIONS_0Eval0Invoker.evaluate(org.drools.spi.Tuple,
> org.drools.rule.Declaration[], org.drools.WorkingMemory,
> java.lang.Object) line: not available
> org.drools.rule.EvalCondition.isAllowed(org.drools.spi.Tuple,
> org.drools.WorkingMemory, java.lang.Object) line: 117
> org.drools.reteoo.EvalConditionNode.assertLeftTuple(org.drools.reteoo.LeftTuple,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory) line: 180
> org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory,
> org.drools.reteoo.LeftTuple) line: 117
> org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(org.drools.reteoo.LeftTuple,
> org.drools.reteoo.RightTuple,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory, boolean) line: 28
> org.drools.reteoo.JoinNode.assertObject(org.drools.common.InternalFactHandle,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory) line: 175
> org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(org.drools.common.InternalFactHandle,
> org.drools.spi.PropagationContext,
> org.drools.common.InternalWorkingMemory) line: 42
> org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(org.drools.reteoo.ObjectSinkPropagator,
> org.drools.common.InternalWorkingMemory) line: 326
> org.drools.reteoo.PropagationQueuingNode.propagateActions(org.drools.common.InternalWorkingMemory)
> line: 221
> org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(org.drools.common.InternalWorkingMemory)
> line: 394
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
> line: 1486
> org.drools.common.NamedEntryPoint.insert(org.drools.common.InternalFactHandle,
> java.lang.Object, org.drools.rule.Rule,
> org.drools.spi.Activation) line: 158
> org.drools.common.NamedEntryPoint.insert(java.lang.Object,
> boolean, boolean, org.drools.rule.Rule,
> org.drools.spi.Activation) line: 122
> org.drools.common.NamedEntryPoint.insert(java.lang.Object)
> line: 80
> com.continuent.tungsten.cluster.manager.rules.engine.RulesEngine.insertFact(com.continuent.tungsten.commons.cluster.resource.notification.NotificationStreamID,
> java.lang.Object, boolean) line: 162
> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager.run()
> line: 249
> java.lang.Thread.run() line: 595
>
> The rule implicated in the above thread is:
>
> rule "IF IN MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS"
> salience 999
>   when
>     notification : ClusterResourceNotification()
> from entry-point "MONITORING"
>     eval(policyMgr.getMode() ==
> ClusterPolicyManagerMode.MAINTENANCE)
>   then
>      statistics.increment("IF IN
> MAINTENANCE MODE, CONSUME ALL NOTIFICATIONS");
>     retract(notification);
> end
>
>
>
> This other thread, apparently a scheduled thread for a rule
> with a 10 second duration,
> is attempting to insert a fact and owns the 'lock.lock' on
> ReteooStatefulSession and
> is waiting for the 'ReteooStatefulSession.actionQueue'.
>
> owns: org.drools.common.DefaultAgenda  (id=4046)
> waiting for: java.util.LinkedList<E>  (id=207)
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).executeQueuedActions()
> line: 1480
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(org.drools.common.InternalFactHandle,
> java.lang.Object, org.drools.rule.Rule,
> org.drools.spi.Activation, org.drools.reteoo.ObjectTypeConf)
> line: 1051
> org.drools.reteoo.ReteooStatefulSession(org.drools.common.AbstractWorkingMemory).insert(java.lang.Object,
> boolean, boolean, org.drools.rule.Rule,
> org.drools.spi.Activation) line: 1001
> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object,
> boolean) line: 114
> org.drools.base.DefaultKnowledgeHelper.insert(java.lang.Object)
> line: 108
> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0.consequence(org.drools.spi.KnowledgeHelper,
> com.continuent.tungsten.commons.cluster.resource.notification.DataServerNotification,
> org.drools.FactHandle, java.lang.String,
> org.drools.FactHandle,
> com.continuent.tungsten.cluster.manager.policy.EnterprisePolicyManager,
> org.apache.log4j.Logger) line: not available
> com.continuent.tungsten.cluster.manager.policy.Rule_DETECT_MONITORING_HAS_STOPPED_0ConsequenceInvoker.evaluate(org.drools.spi.KnowledgeHelper,
> org.drools.WorkingMemory) line: not available
> org.drools.common.DefaultAgenda.fireActivation(org.drools.spi.Activation)
> line: 934
> org.drools.common.Scheduler$DuractionJob.execute(org.drools.time.JobContext)
> line: 70
> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
> line: 132
> org.drools.time.impl.JDKTimerService$JDKCallableJob.call()
> line: 110
> java.util.concurrent.FutureTask$Sync.innerRun() line: 269
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(java.util.concurrent.FutureTask<V>).run()
> line: 123
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.access$301(java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask)
> line: 65
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run()
> line: 168
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(java.lang.Runnable)
> line: 650
> java.util.concurrent.ThreadPoolExecutor$Worker.run() line:
> 675
> java.lang.Thread.run() line: 595
>
> The rule for this task looks like:
> rule "DETECT MONITORING HAS STOPPED"
> duration(10s)
> salience 1000
>   when
>     lastNotification :
> DataServerNotification($resourceName : resourceName)
>
>   from entry-point "MONITORING"
>
>     not (DataServerNotification(resourceName ==
> $resourceName,
>
>
>    this after [10s] lastNotification)
>
>   from entry-point "MONITORING")
>
>     not (ManagerFailedAlarm(expired == false,
>
>    resourceName == $resourceName))
>
>     not (DataSource(name == $resourceName,
>
>    state == ResourceState.SHUNNED ||
>
>    state == ResourceState.FAILED))
>
>   then
>     Object[] params = {$resourceName};
>     if (policyMgr.getMode() !=
> ClusterPolicyManagerMode.MAINTENANCE)
>     {
>
> lastNotification.setResourceState(ResourceState.UNKNOWN);
>       ManagerFailedAlarm alarm =
>
>         new
> ManagerFailedAlarm(lastNotification, "rule detected monitor
> stop",
>
>
>    6, AlarmSeverity.FAULT);
>       logger.info(alarm.toString());
>       insert(alarm);
>       update(lastNotification);
>      }
> end
>
>
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev




--
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat <at> www.jboss.com

_______________________________________________
rules-dev mailing list
rules-dev <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Gmane