3:34 a.m.
Hello,
I am involved in a project in which we are using Drools as the BPM.
We are experiencing some problems with wait state nodes. More concretely,
the problem seems to deal with
the execution of constraints in those wait states.
Let me first describe our context:
We are using JPA with Hibernate and Oracle. Our process instances are all
identified by a
business identifier (a string). This business identified would correspond to
the identifier of a case;
and a case normally has associated a process instances (and subprocesses of
that process).
Additionally, the processes we have developed make extensive
use of timers and wait states with constraints that refer to the process
instance and other facts that
we are using as events.
We have a stateful session for every case / business identifier.
We have a main process that calls subprocesses. As we said, in that process
and subprocesses we use wait states.
The constraints in those wait states are "waiting" for a fact to be inserted
in the stateful session. Once
the corresponding fact is inserted, the corresponding constraint should be
activated.
At this point is where the problem arises. All the constraints have been
unit tested with no problem at all.
But we have detected some problems that can arise when there is more that
one process waiting in the same wait state
(every process in a different Drools stateful session).
The situation is as follows:
1. There is a main process instance MPA with business id BA that has a
subprocess SPA (also with the same business id).
This subprocess is waiting in a given wait state W1 (these processes are
running in the stateful
session corresponding to the business id BA, from now on SA).
2. There is a second main process and subprocess with business id BB. The
state for these second set of processes is the
same one, and they are running in a second stateful session (the one for
business id BB), from now on SB.
3. A fact FA is inserted in SA. This fact makes the constaint in SPA true,
which makes SPA to leave the wait
state and continue with the execution.
Then, in some situations stateful session SA tries to also continue SPB,
which runs in a different stateful session
(that of SB). That, of course, produces some posterior problems that were
the origin of our investigations.
After some more deep investigations, it seems that the reason session SA
tries to continue SPB is that the constraint
in W1 for SPA gets activated twice. We have detected (and posteriorly
corrected) some situations in which this happens.
For example: the process in the constraint was associated not only to SPA
but to other processes in SA (the main process SPA for example).
we corrected this and obtained a better behaviour in which the problem is
more difficult to reproduce.
We have tried also to replace constraints with rule nodes, and set the
lock-on-active and no-loop. The results were a bit different
but seemed not to avoid the problem.
So, there is someone that has experimented situations similar to the
described above? Additionally, can someone from the drools
team give a bit of light to this situation? Why the reasonings in a stateful
session are interacting with processes running on a different
stateful session?
many thanks in advance,
Jordi Alvarez
10:47 a.m.
Hi, after a bit more of study we have seen that the problem is in the JPA
Query defined in META-INF/orm.xml of drools-persistence-jpa-5.1.1.jar
(ProcessInstancesWaitingForEvent).
This query, for version 5.1.1 of drools seems not to be prepared for storing
multiple stateful sessions in the same database schema.
In fact, the original query we got from the .jar was not properly working,
and, while in project startup, we created our own orm.xml file with an
updated query, such as described in:
http://www.mail-archive.com/rules-users@lists.jboss.org/msg16068.html
But the "good" query (and also the original in the jar file) seems to be not
prepared for working with more than one stateful session stored in the same
database schema and having exactly the same constraint "activated". Should
we open a JIRA for this?
We have looked at source code in version 5.2 / jBPM 5, and the query is
similar, with no reference to the stateful session. It should really be
prepared for multiple sessions stored in the same database schema?
thanks again,
Jordi Alvarez
2011/6/22 Jordi Alvarez <jalvarezc(a)gmail.com>
Hello,
I am involved in a project in which we are using Drools as the BPM.
We are experiencing some problems with wait state nodes. More concretely,
the problem seems to deal with
the execution of constraints in those wait states.
Let me first describe our context:
We are using JPA with Hibernate and Oracle. Our process instances are all
identified by a
business identifier (a string). This business identified would correspond
to the identifier of a case;
and a case normally has associated a process instances (and subprocesses of
that process).
Additionally, the processes we have developed make extensive
use of timers and wait states with constraints that refer to the process
instance and other facts that
we are using as events.
We have a stateful session for every case / business identifier.
We have a main process that calls subprocesses. As we said, in that process
and subprocesses we use wait states.
The constraints in those wait states are "waiting" for a fact to be
inserted in the stateful session. Once
the corresponding fact is inserted, the corresponding constraint should be
activated.
At this point is where the problem arises. All the constraints have been
unit tested with no problem at all.
But we have detected some problems that can arise when there is more that
one process waiting in the same wait state
(every process in a different Drools stateful session).
The situation is as follows:
1. There is a main process instance MPA with business id BA that has a
subprocess SPA (also with the same business id).
This subprocess is waiting in a given wait state W1 (these processes are
running in the stateful
session corresponding to the business id BA, from now on SA).
2. There is a second main process and subprocess with business id BB. The
state for these second set of processes is the
same one, and they are running in a second stateful session (the one for
business id BB), from now on SB.
3. A fact FA is inserted in SA. This fact makes the constaint in SPA true,
which makes SPA to leave the wait
state and continue with the execution.
Then, in some situations stateful session SA tries to also continue SPB,
which runs in a different stateful session
(that of SB). That, of course, produces some posterior problems that were
the origin of our investigations.
After some more deep investigations, it seems that the reason session SA
tries to continue SPB is that the constraint
in W1 for SPA gets activated twice. We have detected (and posteriorly
corrected) some situations in which this happens.
For example: the process in the constraint was associated not only to SPA
but to other processes in SA (the main process SPA for example).
we corrected this and obtained a better behaviour in which the problem is
more difficult to reproduce.
We have tried also to replace constraints with rule nodes, and set the
lock-on-active and no-loop. The results were a bit different
but seemed not to avoid the problem.
So, there is someone that has experimented situations similar to the
described above? Additionally, can someone from the drools
team give a bit of light to this situation? Why the reasonings in a
stateful session are interacting with processes running on a different
stateful session?
many thanks in advance,
Jordi Alvarez
12:05 p.m.
Hello, regarding this point,
As a temporal patch, we have tried to directly modify drools-jpa
module behaviour by:
- Adding a new attribute to
org.drools.persistence.processinstance.ProcessInstanceInfo POJO identifying
the stateful session to which the process instance corresponds (and the
corresponding DB column).
- modifying the ProcessInstancesWaitingForEvent query in order to take into
account the session id as a (new) second parameter.
- modify the class org.drools.persistence.processinstance.JPASignalManager
in order to execute the query with both parameters.
- as a quick way to have the session id, we have a threadlocal.
After these modifications have been performed, the execution of processes
with intensive use of wait states has executed correctly, and no confussion
has been detected between process instances after the execution of some
stress tests that previously originated a lot of instances of the problem.
We will open an incident in Drools-JIRA regarding this issue.
best regards,
Jordi Alvarez
2011/6/22 Jordi Alvarez <jalvarezc(a)gmail.com>
Hi, after a bit more of study we have seen that the problem is in the
JPA
Query defined in META-INF/orm.xml of drools-persistence-jpa-5.1.1.jar
(ProcessInstancesWaitingForEvent).
This query, for version 5.1.1 of drools seems not to be prepared for
storing multiple stateful sessions in the same database schema.
In fact, the original query we got from the .jar was not properly working,
and, while in project startup, we created our own orm.xml file with an
updated query, such as described in:
http://www.mail-archive.com/rules-users@lists.jboss.org/msg16068.html
But the "good" query (and also the original in the jar file) seems to be
not prepared for working with more than one stateful session stored in the
same database schema and having exactly the same constraint "activated".
Should we open a JIRA for this?
We have looked at source code in version 5.2 / jBPM 5, and the query is
similar, with no reference to the stateful session. It should really be
prepared for multiple sessions stored in the same database schema?
thanks again,
Jordi Alvarez
2011/6/22 Jordi Alvarez <jalvarezc(a)gmail.com>
> Hello,
>
> I am involved in a project in which we are using Drools as the BPM.
>
> We are experiencing some problems with wait state nodes. More concretely,
> the problem seems to deal with
> the execution of constraints in those wait states.
>
> Let me first describe our context:
>
> We are using JPA with Hibernate and Oracle. Our process instances are all
> identified by a
> business identifier (a string). This business identified would correspond
> to the identifier of a case;
> and a case normally has associated a process instances (and subprocesses
> of that process).
>
> Additionally, the processes we have developed make extensive
> use of timers and wait states with constraints that refer to the process
> instance and other facts that
> we are using as events.
>
> We have a stateful session for every case / business identifier.
>
> We have a main process that calls subprocesses. As we said, in that
> process and subprocesses we use wait states.
> The constraints in those wait states are "waiting" for a fact to be
> inserted in the stateful session. Once
> the corresponding fact is inserted, the corresponding constraint should be
> activated.
>
> At this point is where the problem arises. All the constraints have been
> unit tested with no problem at all.
>
> But we have detected some problems that can arise when there is more that
> one process waiting in the same wait state
> (every process in a different Drools stateful session).
>
> The situation is as follows:
>
> 1. There is a main process instance MPA with business id BA that has a
> subprocess SPA (also with the same business id).
> This subprocess is waiting in a given wait state W1 (these processes are
> running in the stateful
> session corresponding to the business id BA, from now on SA).
>
> 2. There is a second main process and subprocess with business id BB. The
> state for these second set of processes is the
> same one, and they are running in a second stateful session (the one for
> business id BB), from now on SB.
>
> 3. A fact FA is inserted in SA. This fact makes the constaint in SPA true,
> which makes SPA to leave the wait
> state and continue with the execution.
>
> Then, in some situations stateful session SA tries to also continue SPB,
> which runs in a different stateful session
> (that of SB). That, of course, produces some posterior problems that were
> the origin of our investigations.
> After some more deep investigations, it seems that the reason session SA
> tries to continue SPB is that the constraint
> in W1 for SPA gets activated twice. We have detected (and posteriorly
> corrected) some situations in which this happens.
>
> For example: the process in the constraint was associated not only to SPA
> but to other processes in SA (the main process SPA for example).
> we corrected this and obtained a better behaviour in which the problem is
> more difficult to reproduce.
>
> We have tried also to replace constraints with rule nodes, and set the
> lock-on-active and no-loop. The results were a bit different
> but seemed not to avoid the problem.
>
> So, there is someone that has experimented situations similar to the
> described above? Additionally, can someone from the drools
> team give a bit of light to this situation? Why the reasonings in a
> stateful session are interacting with processes running on a different
> stateful session?
>
> many thanks in advance,
> Jordi Alvarez
>
4905
days inactive
4906
days old
2 comments
1 participants
participants (1)
-
Jordi Alvarez