You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "Michael Vorburger (Jira)" <ji...@apache.org> on 2020/05/03 16:37:00 UTC

[jira] [Commented] (FINERACT-922) Improve SchedulerJobHelper to be more reliable and prevent flaky tests

    [ https://issues.apache.org/jira/browse/FINERACT-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098491#comment-17098491 ] 

Michael Vorburger commented on FINERACT-922:
--------------------------------------------

I spent some time looking into what [~ptuomola] pointed out in FINERACT-855, quote:
{quote}This is a timing issue re scheduling the job: Quartz does not have time to process the job submission before we request the status of the job, and hence when we request the job status, it's neither completed nor currentlyRunning as expected by the code.
{quote}
Here are some notes for my future self, or anyone else interested: So e.g. {{SchedulerJobsTest}}, and 6 other scheduler based tests through their use of {{SchedulerJobHelper}} who's {{executeJob}} function seems to have been copy/pasted from {{SchedulerJobsTest}} (which we could clean up, and make {{SchedulerJobsTest}} also use {{SchedulerJobHelper.executeJob()}}), uses {{/fineract-provider/api/v1/jobs/$jobId?command=executeJob}} to manually trigger running a specific named job. They then wait for a job's {{currentlyRunning}} to be false, and then check the (last entry of) {{jobs/$jobId/runhistory}} to have a success status.

I believe the point [~ptuomola] was making is that it's possible that from when Fineract's {{SchedulerJobApiResource.executeJob()}} runs (Fineract's) {{JobRegisterServiceImpl.executeJob()}}, which callsĀ {{org.quartz.Scheduler.triggerJob()}}, until when {{currentlyRunning}} switches from false to true and back to false, there could be delays and misses. The {{currentlyRunning}} seems to be set to true (only) in {{SchedularWritePlatformServiceJpaRepositoryImpl.processJobDetailForExecution()}}, which is called by {{SchedulerTriggerListener.vetoJobExecution()}}. That *should*, in theory, be quick, but yes, we never know, so making that more robust could be a start I guess.

But there also could be other reasons for failure, such as those OptimisticLockExceptions, causing jobs to fail.

> Improve SchedulerJobHelper to be more reliable and prevent flaky tests
> ----------------------------------------------------------------------
>
>                 Key: FINERACT-922
>                 URL: https://issues.apache.org/jira/browse/FINERACT-922
>             Project: Apache Fineract
>          Issue Type: Improvement
>            Reporter: Michael Vorburger
>            Priority: Critical
>
> [~ptuomola] pointed out in FINERACT-855 that the reason for at least some of our often Randomly Failing Integration Tests in FINERACT-850 is likely that the SchedulerJobHelper has serious issues.
> Improving that helper presumably will help for a number of flaky tests.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)