2^x "garbage" timers are created when rolling back a transaction that involves the execution of a process that includes a timer

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 ).

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.