8 Replies Latest reply on Dec 16, 2009 9:01 AM by mohreece

    task & timers

    jbosspnet

      Hi.
      I am using Jbpm 3.2.3 on Jboss 4.2.3.GA.
      I have many processes where I have to check a condition in a manually or in a automatic way and the check have to be completed into a time range.
      For this target, I use the following task-node:

       <task-node name="check" create-tasks="false" end-tasks="true">
       <event type="node-enter">
       <action class="org.process.StartCheck"></action>
       </event>
       <event type="node-leave">
       <action class="org.process.DefaultEnd"></action>
       </event>
      
       <timer name="check" duedate="2 seconds" repeat="4 seconds">
       <action class="org.process.CheckTimer"></action>
       </timer>
      
       <task name="check-manual">
       <event type="task-start">
       <action class="org.process.DefaultStart"></action>
       </event>
       <event type="task-end">
       <action class="org.process.DefaultEnd"></action>
       </event>
       </task>
      
       <task name="check-automatic">
       <event type="task-start">
       <action class="org.process.DefaultStart"></action>
       </event>
       <event type="task-end">
       <action class="org.process.DefaultEnd"></action>
       </event>
      
       <timer name="check-automatic" duedate="2 seconds" repeat="2 seconds">
       <action class="org.process.AutomaticCheck"></action>
       </timer>
       </task>
      
       <transition to="notify success" name="OK"></transition>
       <transition to="notify failure" name="KO"></transition>
       </task-node>
      


      The manual check (first task) uses a form where the user manually clicks on OK/KO buttons.
      Automatic check (second task) is performed with a class in the timer action that executes a query on a database and signal to the corret OK/KO transition.

      To the events node-leave, node-enter, task-start and task-end are associated classes (DefaultStart and DefaultEnd) to trace the execution.

      StartCheck creates the correct task (from a configuration parameter):
       public abstract class StartCheck implements ActionHandler {
       @Override
       public void execute(ExecutionContext executionContext) throws Exception {
       // get check type (manual or automatic)
       // checkType = ...
      
       // get the task-name from the check type (check-manual or check-automatic)
       // taskName = ...
      
       // create task instance
       TaskNode taskNode = (TaskNode) executionContext.getNode();
      
       Task task = taskNode.getTask(taskName);
      
       Token token = executionContext.getToken();
      
       TaskMgmtInstance tmi = executionContext.getTaskMgmtInstance();
      
       TaskInstance taskInstance = tmi.createTaskInstance(task, token);
      
       taskInstance.start();
       }
       }
      


      CheckTimer notifies if the check is over:
       public abstract class CheckTimer implements ActionHandler {
       @Override
       public void execute(ExecutionContext executionContext) throws Exception {
       // get time range (startDate and endDate) from configuration parameters
      
       // checks that new Date() is in the range (startDate, endDate)
      
       // notify user
       }
       }
      


      AutomaticCheck executes the automatic check:
       public abstract class AutomaticCheckAction implements ActionHandler {
       @Override
       public void execute(ExecutionContext executionContext) throws Exception {
       // isOK is setted after a query on a database
       boolean isOK = ...
      
       Token token = executionContext.getToken();
       token.signal(isOK ? "OK" : "KO");
       }
       }
      


      When the execution enters in this node, the task creation is correct and also the task-node timer is created.
      If the check type is manual then the execution stops in the check-manual task and with the form we can select the OK/KO transition.
      But if the check type is automatic, the timer associated with the check-automatic task is never created (in the JBPM_JOB table I find only the row that refers to the task-node timer) and the execution stops in this task forever due to the non-execution of the AutomaticCheck action.

      Why the "check-automatic" task timer is not created?

      Regards.


        • 1. Re: task & timers
          jbosspnet

          Any idea for this?
          Thanks.

          • 2. Re: task & timers
            mohreece

            From the code you supplied I cannot see why the timer is not created (I'm assuming that you're not using abstract classes as handlers and that the class name for the task timer action handler does match in your actual code, because otherwise you'd have other problems running your example). At a first glance it seems to be OK...

            What should happen is that an automatic task instance is created upon the node-enter event, when the StartCheck handler is executed and the TaskMgmtInstance.createTaskInstance(...) method is called; this should trigger the task-create event by which the CreateTimerAction should be executed (which was inserted when the process definition containing the task node was parsed from its XML form).

            This CreateTimerAction is supposed to be creating the timer instance in the Scheduler service (i.e. saving the timer job on the JobSession).

            My advice would be to crank up the logging levels to reveal the jBPM debug entries and see whether the expected events occur and if the timer is saved to the JobSession. Then you may be able to backtrace what went wrong...

            I'm aware this is not too helpful yet, but from the given code it's all the help I can offer you so far...

            • 3. Re: task & timers
              jbosspnet

              Thanks for the reply.
              The java code that I have supplied is in effect incorrect: the classes are not abstract. My processes are a little more complex, so I had simplified before post in the forum to avoid a lot of code. But the concept of the check executed in a specific range time in a manual or in a automatic way is however my target.

              I have followed your suggestion and from Jboss log I have seen that both timers are created by CreateTimerAction. The problem is the signal in the AutomaticCheckAction: this will fire an before-signal and a node-leave event on the task-node. The first is not handled but the second, due to end-task="true" attribute, will cause an task-end event, so the timer in the task will be removed.

              So I have tried to change the process definition with end-task="false" (the default) to preserve both timers when the execution follows KO transition. (As you can guess, this transition goes into a node where I notify the KO status (with a log message or a mail) and the returns into the task-node "check".)
              Now I obtain the following exception:


              org.jbpm.graph.def.DelegationException: org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:382)
               at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
               at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
               at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
               at java.lang.reflect.Method.invoke(Method.java:597)
               at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
               at org.jbpm.graph.def.ProcessDefinition_$$_javassist_184.raiseException(ProcessDefinition_$$_javassist_184.java)
               at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:373)
               at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:276)
               at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:215)
               at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:185)
               at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:169)
               at org.jbpm.graph.def.Node.leave(Node.java:381)
               at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:209)
               at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
               at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
               at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
               at java.lang.reflect.Method.invoke(Method.java:597)
               at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
               at org.jbpm.graph.def.Node_$$_javassist_252.leave(Node_$$_javassist_252.java)
               at org.jbpm.graph.exe.Token.signal(Token.java:192)
               at org.jbpm.graph.exe.Token.signal(Token.java:155)
               at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
               at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
               at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
               at java.lang.reflect.Method.invoke(Method.java:597)
               at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
               at org.jbpm.graph.exe.Token_$$_javassist_186.signal(Token_$$_javassist_186.java)
              


              in the AutomaticCheckAction at line

              token.signal(isOK ? "OK" : "KO");
              


              This exception is also present int JBPM_JOB.EXCEPTION_ column.

              I have notice that whan the execution leaves the task-node a CancelTimerAction will be invoked. This probably suggests that I never leave the node and the KO notification must be done in the task (in the AutomaticCheckAction). But this solution is valid only for the automatic check, not for the manual where I explicity click on a OK/KO form (and the notification can be done only in another node).

              Any suggestions or any another approach?

              Regards.





              • 4. Re: task & timers
                mohreece

                Unfortunately your stack trace doesn't show the real (original) exception, maybe there is a 'caused by' trace underneath it? But from this one, more particular the line

                at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:276)

                we are able to see that the exception originates in the executeAction(...) method, indicating there's either an exception is thrown in the execution of the Action (and thus most likely in the ActionHandler), or something went wrong in the locking of the Token (and that would be my first guess here).

                When you signal a Token from within an ActionHandler, chances are that the call executing the ActionHandler already locked the Token (for the duration of the Action's execution, see GraphElement.java lines 241-264). The signal call causes the node-leave event, which in turn causes your DefaultEnd handler to be called... but before it gets there it tries to lock the Token - again.

                A signal should be used 'from the outside' to trigger a process instance to move on, from the inside it's possibly safe (depends on the node type really) to directly use the leave(...) method. You can try replacing the line
                token.signal(isOK ? "OK" : "KO");

                with
                executionContext.getNode().leave(executionContext, isOK ? "OK" : "KO");

                to see whether this works for you.

                Hope this helps a bit more!

                • 5. Re: task & timers
                  jbosspnet

                  To trace the execution of the process, the DefaultStart and DefaultEnd actions uses an EJB to write some information into a database.
                  The code is the following (Manager and ManagerHome are remote/local interfaces of the EJB):


                  public class DefaultStart implements ActionHandler {

                      Override

                      public void execute(ExecutionContext executionContext) throws Exception {

                          Manager manager = Utils.getManager(executionContext);

                         

                          manager.startJob(...); // some trace parameters like node name, etc.

                      }

                  }

                   

                  public class Utils {
                      private static final Log log = LogFactory.getLog(Utils.class);
                     
                      private static String MANAGER_HOME_JNDI_NAME  = "...";  // jndi name of ejb home interface
                     
                      public static Manager getManager(ExecutionContext executionContext) throws Exception {
                          InitialContext context = null;
                          try {
                              context = new InitialContext(getJndiProperties());
                             
                              Object homeObject = context.lookup(MANAGER_HOME_JNDI_NAME);
                     
                              ManagerHome home = (ManagerHome) PortableRemoteObject.narrow(homeObject, ManagerHome.class);
                             
                              Manager manager = home.create();
                             
                              return manager;
                          } catch (Exception e) {
                              log.error("cannot create manager", e);
                             
                              throw new RuntimeException(e);
                          } finally {
                              if (context != null) {
                                  try {
                                      context.close();
                                  } catch (Exception e) {
                                      // ok
                                  }
                              }
                          }
                      }
                  }

                   

                  (the same for DefaultEnd but with the invocation of manager.endJob(...). )

                   

                  The problem arise at line  

                   

                      Manager manager = home.create()

                   

                  in the DefaultEnd action.

                   

                  Here it is the complet stack trace:

                   

                  2009-12-14 10:51:43,192 ERROR [org.process.Utils] cannot create manager
                  java.rmi.AccessException: SecurityException; nested exception is:
                      javax.security.auth.login.LoginException: no login for this user: null
                      at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:388)
                      at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:136)
                      at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
                      at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.java:637)
                      at org.jboss.ejb.Container.invoke(Container.java:981)
                      at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                      at java.lang.reflect.Method.invoke(Method.java:597)
                      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
                      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
                      at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
                      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
                      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
                      at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169)
                      at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
                      at org.jboss.invocation.InvokerInterceptor.invokeLocalMarshalled(InvokerInterceptor.java:295)
                      at org.jboss.invocation.MarshallingInvokerInterceptor.invoke(MarshallingInvokerInterceptor.java:61)
                      at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
                      at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
                      at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184)
                      at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
                      at $Proxy86.create(Unknown Source)
                      at org.process.Utils.getManager(Utils.java:36) --> LINE "Manager manager = home.create();"
                      at org.process.DefaultEnd.execute(DefaultEnd.java:21) --> LINE "Manager manager = Utils.getManager(executionContext);"
                      at org.jbpm.graph.def.Action.execute(Action.java:122)
                      at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:259)
                      at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:215)
                      at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:185)
                      at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:169)
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                      at java.lang.reflect.Method.invoke(Method.java:597)
                      at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
                      at org.jbpm.taskmgmt.def.Task_$$_javassist_29.fireEvent(Task_$$_javassist_29.java)
                      at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:452)
                      at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:393)
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                      at java.lang.reflect.Method.invoke(Method.java:597)
                      at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
                      at org.jbpm.taskmgmt.exe.TaskInstance_$$_javassist_26.end(TaskInstance_$$_javassist_26.java)
                      at org.jbpm.graph.node.TaskNode.removeTaskInstanceSynchronization(TaskNode.java:273)
                      at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:208)
                      at org.jbpm.graph.def.Node.leave(Node.java:368)
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                      at java.lang.reflect.Method.invoke(Method.java:597)
                      at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
                      at org.jbpm.graph.def.Node_$$_javassist_80.leave(Node_$$_javassist_80.java)
                      at org.process.AutomaticCheckAction.execute(AutomaticCheckAction.java:37)
                      at org.jbpm.graph.def.Action.execute(Action.java:122)
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                      at java.lang.reflect.Method.invoke(Method.java:597)
                      at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
                      at org.jbpm.graph.def.Action_$$_javassist_34.execute(Action_$$_javassist_34.java)
                      at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:259)
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                      at java.lang.reflect.Method.invoke(Method.java:597)
                      at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
                      at org.jbpm.taskmgmt.def.Task_$$_javassist_29.executeAction(Task_$$_javassist_29.java)
                      at org.jbpm.job.Timer.execute(Timer.java:56)
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                      at java.lang.reflect.Method.invoke(Method.java:597)
                      at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
                      at org.jbpm.job.Job_$$_javassist_84.execute(Job_$$_javassist_84.java)
                      at org.jbpm.job.executor.JobExecutorThread.executeJob(JobExecutorThread.java:173)
                      at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:64)
                  Caused by: javax.security.auth.login.LoginException: no login for this user: null
                  ...

                   

                   

                  The jbpm-cfg.xml file is:

                   

                  <jbpm-configuration>
                      <jbpm-context>
                          <service name="persistence" factory="org.jbpm.persistence.db.DbPersistenceServiceFactory" />
                          <service name="tx" factory="org.jbpm.tx.TxServiceFactory" />
                          <service name="message" factory="org.jbpm.msg.db.DbMessageServiceFactory" />
                          <service name="scheduler" factory="org.jbpm.scheduler.db.DbSchedulerServiceFactory" />
                          <service name="logging" factory="org.jbpm.logging.db.DbLoggingServiceFactory" />
                          <service name="authentication" factory="org.jbpm.security.authentication.DefaultAuthenticationServiceFactory" />
                        </jbpm-context>

                   

                    <!-- configuration property used by persistence service impl org.jbpm.persistence.db.DbPersistenceServiceFactory -->
                    <string name="resource.hibernate.cfg.xml" value="hibernate.cfg.xml" />

                   

                    <!-- configuration resource files pointing to default configuration files in jbpm-jpdl.jar -->
                    <string name="resource.business.calendar" value="org/jbpm/calendar/jbpm.business.calendar.properties" />
                    <string name="resource.default.modules" value="org/jbpm/graph/def/jbpm.default.modules.properties" />
                    <string name="resource.converter" value="org/jbpm/db/hibernate/jbpm.converter.properties" />
                    <string name="resource.action.types" value="org/jbpm/graph/action/action.types.xml" />
                    <string name="resource.node.types" value="org/jbpm/graph/node/node.types.xml" />
                    <string name="resource.parsers" value="org/jbpm/jpdl/par/jbpm.parsers.xml" />
                    <string name="resource.varmapping" value="org/jbpm/context/exe/jbpm.varmapping.xml" />
                    <string name="resource.mail.templates" value="jbpm.mail.templates.xml" />

                   

                    <int    name="jbpm.byte.block.size" value="1024" singleton="true" />
                    <string name="jbpm.mail.smtp.host" value="localhost" />
                    <bean   name="jbpm.task.instance.factory" class="org.jbpm.taskmgmt.impl.DefaultTaskInstanceFactoryImpl" singleton="true" />
                    <bean   name="jbpm.variable.resolver" class="org.jbpm.jpdl.el.impl.JbpmVariableResolver" singleton="true" />
                    <bean   name="jbpm.mail.address.resolver" class="org.jbpm.identity.mail.IdentityAddressResolver" singleton="true" />

                   

                    <bean name="jbpm.job.executor" class="org.jbpm.job.executor.JobExecutor">
                      <field name="jbpmConfiguration"><ref bean="jbpmConfiguration" /></field>
                      <field name="name"><string value="JbpmJobExecutor" /></field>
                      <field name="nbrOfThreads"><int value="1" /></field>
                      <field name="idleInterval"><int value="5000" /></field>
                      <field name="maxIdleInterval"><int value="3600000" /></field> <!-- 1 hour -->
                      <field name="historyMaxSize"><int value="20" /></field>
                      <field name="maxLockTime"><int value="600000" /></field> <!-- 10 minutes -->
                      <field name="lockMonitorInterval"><int value="60000" /></field> <!-- 1 minute -->
                      <field name="lockBufferTime"><int value="5000" /></field> <!-- 5 seconds -->
                    </bean>
                  </jbpm-configuration>

                  • 6. Re: task & timers
                    mohreece

                    Well, I'm not versed enough in EJB to tell you what's wrong with the EJB authentication, but it seems that the user credentials are not passed along the way they are getting for the other (successful) calls to your DefaultStart and DefaultEnd. Sorry, but can't help you out on that one...

                     

                    The stack trace does reveal that now your automatic task is run and that it is attempted to leave the node over the indicated transition, using the Node.leave(...) method. Because you configured end-tasks="true" in the TaskNode parameters, the corresponding node-leave event triggers the call to DefaultEnd.

                    Now while I'm definitely not sure that this sequence, which somehow seems in the wrong order to me, will cause the problems you're experiencing, it may be an idea (albeit admittedly far-fetched) to try another approach and instead of my earlier suggestion of calling leave(...) you could end the task from the timer action:

                     

                    {code}executionContext.getTaskInstance().end(isOK ? "OK" : "KO");{code}

                     

                    This does call a signal(...) under the hood, so it probably just might set you back a step...

                     

                    It just dawned on me that your process definition/handler implementation combo for the automatic case contains two ways to leave the TaskNode that are both used:

                    • The call to Token.signal(...) (or as I suggested Node.leave(...)).
                    • The call to TaskInstance.end(...), implicitly called upon the node-leave event.

                    In the manual case, the user clicks the button ending the TaskInstance (I'm assuming), so the node-leave event has no un-ended TaskInstances to trigger, and thus you don't run into that problem in this case.

                     

                    Using the suggestion above would also take care of that in the automatic case. Let us know what happens if you give it a try!

                    • 7. Re: task & timers
                      jbosspnet

                      The problem of EJB authentication has been resolved using client authentication with javax.security.auth.login.LoginContext class and a ad-hoc class that implements javax.security.auth.callback.CallbackHandler. It was however a little strange because this problem arise only when I was invoking an EJB method from a timer action, but all was right not invoking the method from a "normal" action.

                       

                      As you have suggested, now I use node.leave(...) approach and I have no exception.

                       

                      Now arise another question. The timers (both task timer and task-node timer) cannot be cancelled because there is a check also for the date range.

                       

                      How can I avoid Jbpm to destroy them (and eventually destroy "manually") ? I need this for both timers.

                       

                      Regards.

                      • 8. Re: task & timers
                        mohreece

                        Mmm... I'm not sure what you want to accomplish here but that seems just to be wrong, timers in jBPM are designed to be cancelled (i.e. a CancelTimerAction is scheduled to delete the timer at the appropriate event for the timer type) when their scope 'ends'.

                         

                        You've got a Node timer (named 'check') that's cancelled upon the node-leave event, and a Task timer (named 'check-automatic') that's cancelled upon the task-end event; the latter may be associated with other events if you configure it with cancel-event parameters.

                         

                        So timers only exist as long as they are applicable... by design. If you want to change that, you'd have to either avoid the CancelTimerActions to be executed (remove the action from the event before it occurs) or override the implementation so it doesn't delete the timers. Both are not very likable options, so perhaps you want to take another look at what it is you're trying to do by delaying that delete!