Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread JOB re-firing, is it possible to control this more finely?
Wed, Oct 28 2020 9:23 AMPermanent Link

Adam Brett

Orixa Systems

I have a job which connects to a remote store.

From time to time the remote store is unavailable.

In this situation the JOB fires repeatedly, I think even more than once per second, as it fails on a COPY FILE line in the JOB, creating an exception after which it re-runs.

The problem is that I think it is hitting the performance of some other areas of my Apps. Apps occasionally return "cannot lock ..." errors when the JOB is mis-firing, and that never normally happens.

To fix this I can use "Run Once" rather than "BETWEEN" in the interval definition, but obviously that risks missing the call to the store, if it is not available at that moment.

Is there a way to change the frequency of re-run for a JOB?

I guess I could add a mechanism to test whether it has been running via a call to the Configuration.JOBs table ... and not re-run it if the "LastRun" value is too close to "Current_Timestamp", that feels scarily recursive, within a call to the JOB itself.

Anyone else worked on this issue?
Wed, Oct 28 2020 11:51 AMPermanent Link

Raul

Team Elevate Team Elevate

On 10/28/2020 9:23 AM, Adam Brett wrote:

> In this situation the JOB fires repeatedly, I think even more than once per second, as it fails on a COPY FILE line in the JOB, creating an exception after which it re-runs.

If you the handle exception it should not re-run - EDB is seeing job
fail and keeps re-trying it

> Is there a way to change the frequency of re-run for a JOB?

Have not done it myself but in theory you can alter normal interval of
the job (this does feel recursive )
- if it fails alter to repeat every X minutes
- if succeeds alter to return to normal interval

You can query the system info job table and only alter if type/Interval
is not correct already to avoid unnecessary alter.


> I guess I could add a mechanism to test whether it has been running via a call to the Configuration.JOBs table ... and not re-run it if the "LastRun" value is too close to "Current_Timestamp", that feels scarily recursive, within a call to the JOB itself.
>

Querying sys info tables itself should be fine - this all assuming
lastrun is actually updated in case of failure (however if it's not then
NextRun probably is neither and should be in the past relative to now
(since job was due and was just run).

Depending on how often you have this issue it might be worthwhile to
consider managing status in a separate status table of your own  - info
like copy interval, last timestamp and status etc (i.e. if success then
wait til next interval, otherwise try again now)

Then you can have job run super frequently (every 5-10 min or whatever
works for you) and it would just check table and potentially do nothing
unless it's time to copy or there was a problem and retry.


Raul
Wed, Oct 28 2020 1:11 PMPermanent Link

Adam Brett

Orixa Systems

Thanks Raul,

This is sensible. I am going to try resetting it to only run for 5 minutes, and create several jobs over the course of the day each with this setting, as it seems the most transparent way to make this work.

I should look into using exceptions, as I rarely use these (especially not for jobs, when the exception would likely occur on an unmonitored server) maybe when I have a bit more time.

>>Querying sys info tables itself should be fine - this all assuming
>>lastrun is actually updated in case of failure

I can confirm that LastRun does get updated even when the JOB doesn't complete ... so it is possible to use it to check whether the JOB you are in has been triggered very recently. I am likely to use this test in other JOBs in the future ... so that is some useful learning from today.


Adam
Image