Uploaded image for project: 'jBPM'
  1. jBPM
  2. JBPM-1119

Timers using EjbSchedulerService are not persisted across JBoss restarts

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • jBPM 3.2.3
    • jBPM 3.2.1
    • Runtime Engine
    • None

      Timers created using the EjbSchedulerService do not fire if JBoss is restarted after the timer is set. The reason
      is that although the JBPM timer row still exists in the database, there is no corresponding EJB timer to kick off
      the JBPM timer action.

      EJB timers are supposed to persist across server restarts but there is a catch. JBPM uses an EJB with a "local"
      interface to dispatch the JBPM timers. JBoss (as of 4.0.2) has decided to make the jndi name of EJBs with
      local interfaces have a unique name by appending an '@' sign and a hashcode to the EJB name. This hash
      code is different every time the server is restarted. When the EJB timers are reloaded after a restart, the EJB
      that is supposed to receive the timer doesn't exist anymore because it now has a different name (different
      hashcode). This causes the timers to be deactivated and they do not fire at the appointed time.

      See http://wiki.jboss.org/wiki/Wiki.jsp?page=WhyDoesTheLocalNameContainARandomNumber for an explanation
      of the EJB name issue for EJBs with a local interface.

      We need a local-jndi-name parameter added to the TimerServiceBean so we can always locate it under the same name
      and the timers will work as expected.

      adding the following to jboss.xml takes care of this issue:

      <session>
      <ejb-name>TimerServiceBean</ejb-name>
      <local-jndi-name>TimerServiceBean</local-jndi-name>
      </session>

              aguizar_jira Alejandro Guizar (Inactive)
              aner_jira Aner Perez (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: