[rules-users] transaction rollback makes the knowledge session multiplicate the timers when executing a processs that has timers bound to human tasks

[Alberto R. Galdo]

Attached you can find a test case that has the following behaviour:

First, there is a process that has two script tasks and one human task that
has bounded an interrupting timer.

The test case, first configures a persistent environment using Bitronix and
H2 ( this has been tested also using JBoss and PostgreSQL ), then a
knowledgebase is configured using the previous BPMN process definition,
then human task service and persistence are configured along with the
defautl human task handler, and an StatefulKnowledgeSession is created.

Then there's a loop of 10 cycles of:

   - Begin transaction
   - Start the process ( then it executes until the timer waits for 30 days
)
   - commit or rollback ( if cycle % 2 )

After that, the serialized KnowledgeSession is retrieved from the database
using just JDBC, and then is rehydrated using ProtobufMarshaller.

Well, what you will be able to see is that rolling back transactions that
involved executing a process that had timers inside, made the timers
multiplicate in the session. ( You can see this by placing a breakpoint
into "ProtobufInputMarshaller [line: 154] -
readSession(MarshallerReaderContext, int, ExecutorService, Environment,
SessionConfiguration)    " and inspecting the contents of the variable
_session ).


>From the code it is expected to find just 5 timers persisted, but when
rehydrating the session one can see that were created 46 timers !!. This is
really weird, but it is weirder to find that there is some kind of pattern
).

If you take a look at what is inside the protocol buffers serialized
version of the knowledge session you can find that there's a direct
relation between the groups in the focus_stack, which in the example is:

    focus_stack {
      group_name: "MAIN"
      group_name: "MAIN"
      group_name: "MAIN"
      group_name: "MAIN"
      group_name: "MAIN"
    }

and the number of repetitions of each timer ( associated with each process
instance ) are multiple of the number of group_names in the agenda. For
example if there are 5 items in the focus_stack there will be no more than
2^4 ( 16 ) repetitions of each timer. But all timers are congruent with
2^x-1 where x is the number of group_name in the agenda.


In fact, if you leave the timer behind ( just by changing the process ) you
will still be able to find that when executed there are 5 !!  group_name
inside the focus_stack.

I've created a bug in Jira   JBPM-3831 :
https://issues.jboss.org/browse/JBPM-3831


Any insight?


Alberto R. Galdo
argaldo at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20121025/181a82be/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase.bpmn
Type: application/octet-stream
Size: 7703 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20121025/181a82be/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BelmezBugTestCase.java
Type: application/octet-stream
Size: 4749 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20121025/181a82be/attachment-0003.obj