Date parsing failure for existing periodical jobs

[SebaDro]

The 2.1.0 release fails for parsing start and end date of existing periodic jobs:

2021-01-06 08:04:03.859 ERROR 1 --- [eduler_Worker-4] org.quartz.core.ErrorLogger              : Job (GROUP.CopernicusSubsetDefinition_sentinel-2_6.918,51.0224,7.6176,51.3268 threw an exception.

org.quartz.SchedulerException: Job threw an unhandled exception.
        at org.quartz.core.JobRunShell.run(JobRunShell.java:213) ~[quartz-2.3.0.jar!/:na]
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573) [quartz-2.3.0.jar!/:na]
Caused by: java.lang.NullPointerException: null
        at org.joda.time.format.DateTimeFormatterBuilder$CharacterLiteral.parseInto(DateTimeFormatterBuilder.java:1225) ~[joda-time-2.9.9.jar!/:2.9.9]
        at org.joda.time.format.DateTimeFormatterBuilder$Composite.parseInto(DateTimeFormatterBuilder.java:2516) ~[joda-time-2.9.9.jar!/:2.9.9]
        at org.joda.time.format.InternalParserDateTimeParser.parseInto(InternalParserDateTimeParser.java:52) ~[joda-time-2.9.9.jar!/:2.9.9]
        at org.joda.time.format.DateTimeFormatterBuilder$MatchingParser.parseInto(DateTimeFormatterBuilder.java:2610) ~[joda-time-2.9.9.jar!/:2.9.9]
        at org.joda.time.format.DateTimeFormatter.parseDateTime(DateTimeFormatter.java:925) ~[joda-time-2.9.9.jar!/:2.9.9]
        at org.joda.time.DateTime.parse(DateTime.java:160) ~[joda-time-2.9.9.jar!/:2.9.9]
        at org.joda.time.DateTime.parse(DateTime.java:149) ~[joda-time-2.9.9.jar!/:2.9.9]
        at de.wacodis.sentinel.SentinelJob.execute(SentinelJob.java:88) ~[sentinel-observer-2.1.0.jar!/:na]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:202) ~[quartz-2.3.0.jar!/:na]
        ... 1 common frames omitted

The existing job for which the parsing failed should be available under the link below: https://job-definition.wacodis.52north.org/jobDefinitions/b7cbbdb3-46c4-4c6f-86cb-9d21c5531c6b

[cDanowski]

Hi,

okay, for existing jobs the relevant dates are indeed not set, as they are set for its dataMap when the job is "registered" within the observer.

For existing jobs that have run at least one time, I was sure, that they should jump into the if part of the following SentinelJob.java code block. As they set the DateTime object under the very same dataMap key. Was your job already registered but without having run at least once?

Maybe it is also a problem that the former implmentation tried to register the DateTime object directly into job dataMap. Arne told me, that might lead to problems during persisting the information. That is why the current implementation writes DateTime object to String and then puts those into job dataMap.

 // If there was a Job execution before, consider the latest request
        // end date as start date for the current request.
        // Else, use the factory level based generic configuration of the first 
        if (dataMap.get(LAST_LATEST_PRODUCT_KEY) != null) {
            startDate = (DateTime) dataMap.get(LAST_LATEST_PRODUCT_KEY);
            endDate = DateTime.now();
        }

        else {
            startDate = DateTime.parse((String)dataMap.get(TemporalCoverageConstants.START_DATE));
            endDate = DateTime.parse((String)dataMap.get(TemporalCoverageConstants.END_DATE));
        }
        dataMap.put(LAST_LATEST_PRODUCT_KEY, endDate);

I tried it with a fresh registration of the specifed job and that worked well, as the relevant parameters are initialized correctly. Would that be an option for the failing job as well? To save its definition, delete it and than reintegrate it as a new job?

[SebaDro]

Was your job already registered but without having run at least once?

Unfortunately, I'm not sure if the job has been executed at least once.

Maybe it is also a problem that the former implmentation tried to register the DateTime object directly into job dataMap. Arne told me, that might lead to problems during persisting the information. That is why the current implementation writes DateTime object to String and then puts those into job dataMap.

That should be the reason why parsing failed. However, should the LAST_LATEST_PRODUCT_KEY DateTime object not be stored as String then, too?

I tried it with a fresh registration of the specifed job and that worked well, as the relevant parameters are initialized correctly. Would that be an option for the failing job as well? To save its definition, delete it and than reintegrate it as a new job?

Yes, I would be fine with it. I will recreate the concerning job within the Job Definition API.

[cDanowski]

yes, you are totally right. I simply used the previous lines of code, when I implemented the new date functionalities. I now ensured that dateTime objects are stored as string in commit c27b77ce6d66cd11eba70255a2f4bbae7f130f0c