NPE for JobExecution#getJobName

[ltvcuong]

When trying to retrieve the running executions of a job but I got a NPE:
Caused by: java.lang.NullPointerException at org.jberet.runtime.JobExecutionImpl.getJobName(JobExecutionImpl.java:141) at org.jberet.operations.JobOperatorImpl.getRunningExecutions(JobOperatorImpl.java:157) at ch.adnovum.monexio.server.batch.rs.BatchOperatorServiceBean.getRunningJobIds(BatchOperatorServiceBean.java:143) at ch.adnovum.monexio.server.batch.rs.BatchOperatorServiceBean.assertAtomicJob(BatchOperatorServiceBean.java:94) at ch.adnovum.monexio.server.batch.rs.BatchOperatorServiceBean.start(BatchOperatorServiceBean.java:54)

looking at the code, i could not tell what the problem was, could some body give me some hints?
(I possted a question http://stackoverflow.com/questions/39074855/jberet-npe-for-jobexecutiongetjobname as well).

thanks in advance.

[chengfang]

Your code path is different from the current version. Which version of JBeret, or which version of WildFly if using JBeret inside WildFly? Can you try the latest version?

[ltvcuong]

I'm using JBeret inside WildFly 8.2.0.Final. The problem is, i've been using it for more than a year without such problem. It's just happened recently and not always, it does not happen on my dev environment and test server but on my integration server, both servers have the same configuration except that we do the DB cleanup for test server for each installation and not for integration.

[chengfang]

Could be related to https://issues.jboss.org/browse/JBERET-191

But issue JBERET-191 is about setting the wrong job instance, not the null job instance.

Looks like some problem during deserializaing job execution data from db. In your dev or test environment, where you cleaned db, there is nothing to deserialize from db, so this problem does not show up. Can you upgrade to recent version of WildFly (e.g., WildFly 10.1)?

[ltvcuong]

Hi, thanks for you hints. So do you think cleaning the job excecution data would help in this case? Upgrading Wildfly is not really a decision i can make...

Actually, i'm still confused: if it's the deserialization problem, it should happen on my test server as well because we would have job execution data in the DB after some time (after the first fun).

[chengfang]

job execution data is also cached. I guess in your test server, those job execution data is present in memory and in db too, so there is no need to deserialize it from db.

In your integration server, somehow those job execution data is not in cache, so JBeret needs to deserialize it from db. And just for this particular use case and code path, a bug like JBERET-191 occurred.

If you cannot upgrade, then the workaround is to make sure the requested job execution data is already in memory, or there is no job execution data in db to deserialize.

To achieve the same result as getRunningExecutions(jobName), you can try first calling getJobInstances(final String jobName, final int start, final int count) to get list of JobInstance, then for each JobInstance, call getJobExecutions(final JobInstance jobInstance) to get a list of JobExecution, then filter them by their batch status.

Again, the best approach is to upgrade to latest stable version of WildFly and JBeret, to benefit from bug fixes like this and other fixes.

[ltvcuong]

thanks a lot for your answer.

I will try the alternative you mentioned. I will get back when i get the result (it usually takes weeks for a fix to go to integration...)