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:
parent
9075dbc61d
commit
d25ae71fef
19 changed files with 171 additions and 74 deletions
15
docs/news/unreleased/request-job-timeout.md
Normal file
15
docs/news/unreleased/request-job-timeout.md
Normal 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue