d25ae71fef
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.
15 lines
832 B
Markdown
15 lines
832 B
Markdown
# 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.
|