[Features] Improvements to the job service

[thoven87]

I think it would be nice to have to the following features:

1 - Retry back-off, currently a job will retry right after failure until it reaches the maxRetryCount: SOME_VALUE, it would be great to introduce a exponential back off strategy.

2 - Delay until, the current implementation process a job right after it was queued. Most of the time it's what we want, but sometimes we want to process a task later. I think adding a delay until can be beneficial with suggestion number 1.

3 - Scheduled Jobs. It would be nice PR landed.

I suppose with the current implementation, one needs Just one Job queue controller to register all jobs. Moreover, If we want to process jobs on another server, we would just not register the job queue service in the service lifecycle?

[adam-fowler]

I think it would be nice to have to the following features:

1 - Retry back-off, currently a job will retry right after failure until it reaches the maxRetryCount: SOME_VALUE, it would be great to introduce a exponential back off strategy.

Yes this is something we should do.

2 - Delay until, the current implementation process a job right after it was queued. Most of the time it's what we want, but sometimes we want to process a task later. I think adding a delay until can be beneficial with suggestion number 1.

This is more complex, and at least for Redis will possibly require some work. But should be doable.

3 - Scheduled Jobs. It would be nice PR landed.

I suppose with the current implementation, one needs Just one Job queue controller to register all jobs. Moreover, If we want to process jobs on another server, we would just not register the job queue service in the service lifecycle?

With the current implementation the scheduler is meant to run on one server and it will add jobs to the queue at scheduled times. Then one of the machines that is servicing the job queue will run the job.

[thoven87]

I think it would be nice to have to the following features: 1 - Retry back-off, currently a job will retry right after failure until it reaches the maxRetryCount: SOME_VALUE, it would be great to introduce a exponential back off strategy.

Yes this is something we should do.

Sweet, I am experimenting with exponential back off for retry in a branch.

2 - Delay until, the current implementation process a job right after it was queued. Most of the time it's what we want, but sometimes we want to process a task later. I think adding a delay until can be beneficial with suggestion number 1.

This is more complex, and at least for Redis will possibly require some work. But should be doable.

I don't know what the impact will be on the Redis job queue yet, I think adding delayUtil in the QueueJob struct can be reused for both schedule later and back off retry.

3 - Scheduled Jobs. It would be nice PR landed. I suppose with the current implementation, one needs Just one Job queue controller to register all jobs. Moreover, If we want to process jobs on another server, we would just not register the job queue service in the service lifecycle?

With the current implementation the scheduler is meant to run on one server and it will add jobs to the queue at scheduled times. Then one of the machines that is servicing the job queue will run the job.

I see, thank you!

[thoven87]

Closing this as all three features have been implemented.