[jboss-jira] [JBoss JIRA] (JBRULES-3391) Rule group activation by concurrent jbpm processes ...

[Jose Cavieres (JIRA)]

    [ https://issues.jboss.org/browse/JBRULES-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091421#comment-13091421 ] 

Jose Cavieres commented on JBRULES-3391:
----------------------------------------

The problem is still happening in 6.2 despite the statement is still present in the documentation.
Is there an error in the documentation or is a bug?



> Rule group activation by concurrent jbpm processes ...
> ------------------------------------------------------
>
>                 Key: JBRULES-3391
>                 URL: https://issues.jboss.org/browse/JBRULES-3391
>             Project: JBRULES
>          Issue Type: Bug
>          Components: drools-core  (expert), drools-core (flow)
>    Affects Versions: 5.4.0.Beta2
>         Environment: Operating system independent.
>            Reporter: Alberto Rodriguez
>            Assignee: Mark Proctor
>
> We've been able to see that the following statement in the documentation doesn't seem to be true:
> "We have added special logic to make sure that a variable processInstance of type WorkflowProcessInstance
> will only match to the current process instance and not to other process instances in the Working Memory."
> We've seen rules fire for rule-group activations from different workflowprocesses.
> Imagine a knowledge session with this set of rules:
> rule "new case"
>     when   
>         $object : Object(processed==false) from entry-point "my stream"       
>     then
>         ProcessInstance processInstance=kcontext.getKnowledgeRuntime().createProcessInstance("my.Process", parameters);
>         insert(processInstance);
> end
> rule "complete"
>     ruleflow-group "process complete"
>     no-loop true
>     when
>         $processInstance: WorkflowProcessInstance()
>     then
>         System.out.println("Fired!" + $processInstance);
> end
> And a process that runs a time consuming task before reaching a bussinessruletask node that calls the "process complete" group of rules.
> What is happening from Drool's expert point of view is the following sequence of events:
>     1 - A fact is inserted that triggers the rule "new case". An Activation is inserted into the agenda.
>     2 - As this is running in a fireUntilHalt loop then, almost inmediatelly, the previous activation is fired and it's consquence is evaluated leading to the insertion of the process instance as a fact in the knowledge session. The process is now executing.
>     3 - This very new fact triggers the activation of the rule "complete"  ( as it's only condition is that a processinstance exists ). It's consequence gets evaluated and as it belongs to a group of rules, an Activation is added to the ruleFlowGroup inside the Agenda. Nothing happens thereafter.
>     4 - Another fact of the same type arrives and steps 1,2 and 3 execute for the new fact. Now, the agenda has two Activations stored in the ruleFlowGroup.
>     5 - At this time, the task in the first process ends, the businessruletask gets executed and JBPM calls "activateRuleFlowGroup" on the Agenda and the rule flow group gets activated.
>     6 - Inmediatelly the group of rules fires two activations ( both queued at process fact insertion when the process was started ), when only one process ended.
>     7 - So at least one rule gets evaluated for a process instance that didn't belong to it .. :(
> Then , "We have added special logic to make sure that a variable processInstance of type WorkflowProcessInstance
> will only match to the current process instance and not to other process instances in the Working Memory." doesn't hold to be true, as our rule is fired *before* it's process asks Drools to do so.
> We've tested this behaviour in Drools 5.1.0, 5.2.0 and 5.3.0. All seem to fail in fulfilling the requirements stated the documentation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)