Announcement Announcement Module
Collapse
No announcement yet.
getLastJobExecution() returns null Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • getLastJobExecution() returns null

    I am working on restarting a job using the JobOperator interface.

    Here's the scenario. I have a failed job execution that I want to restart. I have a test (SpringJUnit4ClassRunner) that restarts the test just fine, but when I try to restart the same job execution running in Weblogic, the jobRepository.getLastJobExecution() fails to find the previous execution.

    I've isolated the problem call to the following in the launcher in the run() method call:

    JobExecution lastExecution = jobRepository.getLastJobExecution(job.getName(), jobParameters);


    the jobOperator.restart(jobExecId) sucessfully finds the parameters and passes them to the run() method of the launcher along with the jobname, but the execution is not found for the parameters.

    It's as though the matching algorithm of the job parameters in the web environment is somehow different that that of the standalone test.

    Is that possible?

  • #2
    Here's a follow up --

    One of the job parameters is a 'runDate' whose value is created by simply calling 'new Date()' as a parameter to the JobParameter constructor. Here is the code for creating the parameters to the job:

    Code:
            Map<String,JobParameter> myParms = new HashMap<String,JobParameter>();
            myParms.put("templateId", new JobParameter(templateId));
            myParms.put("fromAddress", new JobParameter(fromAddress));
            myParms.put("subject", new JobParameter(subject));
            myParms.put("postSendAction", new JobParameter(postSendAction));
            myParms.put("requesterNetId", new JobParameter(requesterNetId));
            myParms.put("batchLogRecipientEmail", new JobParameter("[email protected]"));
            myParms.put("runDate", new JobParameter(new Date()));
            JobParameters parms = new JobParameters(myParms);
    So when the job fails, the 'runDate' parameter is one of the parameters that will be checked to see if there has been a previous execution of the job instance.

    I forced a job to fail through an integration test running in a separate Java process from the web application.

    The web application was running in an environment with a system property set for the timezone: -Duser.timezone=US/Central, because I was recently upgraded to Windows7 and for some reason, Java was picking up the timezone of PKT (Pakistan). So the upshot was that the web application is running in a different timezone than the integration test that created the original failed job.

    When Spring Batch running in the web application environment went to look for the previously executed job, it could not find it because there was something different about the value of the 'runDate' job parameter. By removing the -Duser.timezone java system property and restarting the web application, the previously executed (failed) job was found.

    I don't understand why this is the case. My understanding was that regardless of the timezone setting of the individual processes, the stored date for the parameter would be interpreted correctly, but that seems not to be the case.

    Does anyone know if the stored date value in Spring Batch retains some timezone information?

    Comment


    • #3
      You are using MySQL? If so then it's a platform issue. In any case you probably just need to use a Long instead of a Date to store the parameter value if it has millisecond accuracy, or round it down to the nearest second.

      Comment


      • #4
        Nope . . . using Oracle.

        Comment


        • #5
          Does it work if you use a Long instead of a Date?

          Comment

          Working...
          X