The Java client provides a job worker that takes care of polling for available jobs and allows you to focus on writing code to handle the activated jobs.
open the job worker waits
pollInterval milliseconds and then polls for
It then continues with the following schedule:
- when a poll did not activate any jobs, it waits for
pollIntervalmilliseconds and then polls for more jobs.
- when a poll activated jobs, the worker submits each job to the job handler.
Every time a job is handled, the worker checks whether the number of unhandled jobs have dropped below 30% of
maxJobsActive. The first time that happens, it will poll for more jobs.
- when a poll fails with an error response, a backoff strategy is applied.
It waits for the delay provided by the
backoffSupplierand then polls for more jobs.
When a poll fails with an error response, the job worker applies a backoff strategy. It waits for some time, after which it polls again for more jobs. This gives a Zeebe cluster some time to recover from a failure. In some cases, you may want to configure this backoff strategy to better fit your situation.
The retry delay (i.e. the time the job worker waits after an error before the next poll for new jobs) is provided by the
You can replace it using the
.backoffSupplier() method on the
By default, the job worker uses an exponential backoff implementation, which can you can configure using
The backoff strategy is especially useful for dealing with the
GRPC_STATUS_RESOURCE_EXHAUSTED error response (see gRPC Technical Error Handling).
This error code indicates the Zeebe cluster is currently under too much load and has decided to reject this request.
By backing off, the job worker helps Zeebe by reducing the load.
Note, that Zeebe's backpressure mechanism can also be configured.