4 Replies Latest reply on May 17, 2016 9:18 AM by johnnuy

    JBeret JDBC Job Repository in EAP 7 Beta

    johnnuy
    johnnuy May 12, 2016 9:14 AM

      Hi,

       

      I'm doing some investigation into the usability of the JBeret integration with EAP 7.  Configured as follows in my standalone.xml

       

      <subsystem xmlns="urn:jboss:domain:batch-jberet:1.0">

      <default-job-repository name="db"/>

      <default-thread-pool name="batch"/>

      <job-repository name="db">

      <jdbc data-source="JBeretDS"/>

      </job-repository>

      <thread-pool name="batch">

      <max-threads count="10"/>

      <keepalive-time time="30" unit="seconds"/>

      </thread-pool>

      </subsystem>

       

      I'm finding that if the jboss server is killed/crashed while a job is Running, that job will always return when I call the BatchRuntime.getJobOperator().getRunningExecutions("myJob").

       

      Additionally the batch status of the JobExecution will return STARTED.

       

      Maybe i'm missing something, but is there a way to detemine which jobs have been interrupted and are in this state?

        • 1. Re: JBeret JDBC Job Repository in EAP 7 Beta
          jamezp
          jamezp May 16, 2016 5:59 PM (in response to johnnuy)

          The problem is during a crash there's no way to update the state of a job since the process is being destroyed. During a controlled shutdown the running jobs should all be stopped and go into a STOPPED status.

           

          You can however restart jobs in that state. See [JBERET-154] Support restarting killed or crashed job execution - JBoss Issue Tracker for details about adding the jberet.restart.mode property to the restart.

           

          --

          James R. Perkins

            • Actions
          • 2. Re: JBeret JDBC Job Repository in EAP 7 Beta
            johnnuy
            johnnuy May 16, 2016 6:15 PM (in response to jamezp)

            Hi James,

             

            Thanks for the reply and the link to the restart property.  The part I'm stuck at is programmatically detecting which jobs that are currently in a "STARTING", "STARTED" or "STOPPING" state, need to be restarted without having someone look at them.

             

            I could write some code to validate the interval since the job status changed, against an expected interval for that status, but this would be a job specific calculation and not entirely reliable.

             

            Is it possible to modify the behaviour of the getRunningExecutions() method to not return these jobs that need to be restarted?

              • Actions
            • 3. Re: JBeret JDBC Job Repository in EAP 7 Beta
              jamezp
              jamezp May 16, 2016 6:27 PM (in response to johnnuy)

              I can't think of a way for JBeret to know which jobs would require restarting.

               

              Depending on your jobs are started you could use a @Startup EJB to query jobs in the STARTING, STARTED or STOPPING state and restart them. This could get a bit messy though if you have jobs being submitted immediately after a restart of the container.

               

              --

              James R. Perkins

                • Actions
              • 4. Re: JBeret JDBC Job Repository in EAP 7 Beta
                johnnuy
                johnnuy May 17, 2016 9:18 AM (in response to jamezp)

                Ok thanks, delaying the job creation until all jobs have been recovered isn't the end of the world.

                  • Actions