worker: Configurable timeout for RequestJob

This is backwards compatible, as long as the timeout is 0 (never
timeout), which is the default.

In case of the dbjobqueue the underlying timeout is due to
context.Canceled, context.DeadlineExceeded, or net.Error with Timeout()
true. For the fsjobqueue only the first two are considered.
This commit is contained in:
sanne 2021-10-18 17:18:47 +02:00 committed by Tom Gundersen
parent 9075dbc61d
commit d25ae71fef
19 changed files with 171 additions and 74 deletions

View file

@ -0,0 +1,15 @@
# Timeout when requesting jobs
When workers request a new job they make a blocking call to the `/api/worker/v1/jobs`
endpoint. There are cases however where a polling approach is more useful, for instance when idle
connections get terminated after a certain period of time.
The new `request_job_timeout` option under the worker config section allows for a timeout on the
`/api/worker/v1/jobs` endpoint. It's a string with `"0"` as default, any string which is parseable
by `time.Duration.ParseDuration()` is allowed however, for instance `"10s"`.
Because this is an expected timeout, "204 No Content" will be returned by the worker server in case
of such a timeout. The worker client will simply poll again straight away.
To maintain backwards compatilibity the default behaviour is still a blocking connection without
timeout.