0

So im using JSR-352 specification for building batch jobs but something strange is hapenning, when i start my job, the batch status(on the control table) is persisted as STARTING and dont change from this. Even when it starts doing the first step on the job.

When it enters the first step of the job, it should be on the state STARTED and not in STARTING, the stranger thing is if i go see the JobContext variable it has the batch status information in the correct state(STARTED).

Can anyone can help me understand why the batch status stays in STARTING, even when it already started executing the job steps?

Thanks in advance.

user3121133
  • 27
  • 7
  • 1
    What implementation/environment are you using? – Scott Kurz Jan 05 '19 at 21:25
  • Hi Scott the server is the weblogic – user3121133 Jan 06 '19 at 17:32
  • Hmm.. can't think of why that'd happen. Assuming weblogic is using the **com.ibm.jbatch** reference impl, the code [here](https://github.com/WASdev/standards.jsr352.jbatch/blob/46d42ea249ebaff37b348f08cd47c38381b3d8e7/com.ibm.jbatch.container/src/main/java/com/ibm/jbatch/container/impl/JobThreadRootControllerImpl.java#L154-L160) shows the status getting set to STARTED for the JobContext and then immediately persisted to the DB. I wonder how you are viewing the status as STARTING? Are you using a Batch API or "directly" querying the DB? I wonder what status the `JobExecution` object shows. – Scott Kurz Jan 07 '19 at 15:06
  • Im seeing on the batch manager web application, that i beleive it querys directly on the db. – user3121133 Jan 07 '19 at 15:29
  • Ive putted logs to see the status of the JobExecution, on my code. Tell me one thing the status is set to started before executing the first step of the job, right? – user3121133 Jan 07 '19 at 15:32
  • When y have the executionId it should already be on STARTED right? – user3121133 Jan 07 '19 at 15:33
  • Not quite. The JobExecution is created in STARTING status. The thread is then passed into the executor (thread pool). It is only when the executor actually decides to execute this thread that the status moves to STARTED. This happens very early on the thread execution, before any application artifacts are executed, so it didn't sound like a match to what you were describing (since you mentioned accessing the JobContext). But ignoring that mention, a symptom of jobs "stuck" in STARTING state could suggest the thread pool / executor had a backlog of threads it hadn't executed yet. – Scott Kurz Jan 07 '19 at 16:43
  • Just noticed your other comment. Yes it will be set to STARTED before the first step begins. – Scott Kurz Jan 07 '19 at 20:40
  • I mentioned accessing the JobContext, because as you said when the status passes from STARTING to STARTED, this status(STARTED) is set to the jobContext and then its persisted on DB. And in debug when i stop the execution in the first step of the Job, the JobContext has the batch status in the correct state (STARTED), but in the DB it is STARTING. – user3121133 Jan 07 '19 at 21:06
  • So the problem maybe is in persisting the status in the DB, after setting it on the JobContext. Do you know any reason for this ??? – user3121133 Jan 07 '19 at 21:09
  • No idea. I guess you might want to question if the "manager" app is showing an accurate, up-to-date view, (which you could check by querying the DB directly perhaps). – Scott Kurz Jan 07 '19 at 21:39
  • Im going to try it, thanks for the hints. – user3121133 Jan 07 '19 at 22:02
  • Scott ive putted logs and when this situation happens the jobExecution.getBatchStatus in the first step of the job is STARTING as well in the DB, but as in the JobContext the batch Status is setted to STARTED. – user3121133 Jan 08 '19 at 11:18
  • I succeded in replicating the problem, when i stop the execution in debug into the ibm code it never happens the status is persisted correctly, but when i dont use any breakpoint on the code it doesnt persist the status correctly(it stays STARTING). – user3121133 Jan 08 '19 at 16:53
  • No idea why the DB wouldn't show an updated status (STARTED). Not sure how the "manager" app is coded or what your other debug methods consist of. If you were using the **JobOperator** API methods to get the **JobExecution**, e.g. `getJobExecution(long executionId)`, I'd suggest you should always get a new **JobExecution** to see the latest status (rather than relying on a cached **JobExecution**, since the behavior here is implementation-specific). – Scott Kurz Jan 08 '19 at 18:41
  • its strange, what i did was decompile the batch jar file and then used the source code to debug internaly on the class. Ive placed a breakpoint on the markJobStarted method in the class JobThreadRootControllerImpl, and it worked fine the batch status was getting persisted correctly on the DB. But without doing debug, just starting the execution of the job without any breakpoint it doesnt persist the status neither the starttime. – user3121133 Jan 08 '19 at 19:03
  • The code is [here](https://github.com/WASdev/standards.jsr352.jbatch/tree/1.0.x) if it helps. I know the mapping between the maven release and git SHA/tags is a bit hard to reconstruct, but there haven't been many changes in the past three years. – Scott Kurz Jan 08 '19 at 19:45

0 Answers0