Configuration

Tune the worker with WorkerOptions, built via its builder and passed to FlareWorker.builder(client).options(...). Every field has a sensible default.

WorkerOptions options = WorkerOptions.builder()
    .concurrency(5)
    .addQueue("default")
    .addQueue("maintenance")
    .pollInterval(Duration.ofSeconds(2))
    .defaultTimeout(Duration.ofMinutes(30))
    .shutdownTimeout(Duration.ofSeconds(30))
    .build();

Options

Builder method	Default	Meaning
concurrency(int)	10	Max jobs processed at once.
addQueue / queues	["default"]	Queues to serve (the registered jobs' queues are also served).
pollInterval(Duration)	2s	Wait between polls when no work is available or all slots are busy.
defaultTimeout(Duration)	30m	Fallback per-job timeout when an enqueued job carries none.
defaultMaxAttempts(int)	3	Default max attempts announced for registered jobs.
shutdownTimeout(Duration)	30s	How long stop() waits for in-flight jobs to drain before forcing.
pollReadTimeout(Duration)	40s	Socket read timeout for the long-poll (must exceed the long-poll window).
heartbeatInterval(Duration)	(derived)	Override the heartbeat cadence (mainly for tests).

Concurrency and backpressure

The worker runs at most concurrency jobs simultaneously. On each poll it asks Flare for only as many jobs as it has free slots (capped so it never requests more than the protocol allows), and it never starts more than its free slots even if more come back. When every slot is busy it idles for pollInterval instead of polling, so a saturated worker doesn't spin.

The default of 10 suits I/O-bound jobs (network, database). Because work is network-bound and capped, raising concurrency well past your downstream capacity won't help; tune it to how much parallel work your dependencies can absorb.

The long-poll

Polling is a long-poll: a single request stays open until a job is available or the window elapses. The worker uses its own read timeout for this (separate from the thin client's request timeout) so polling is never cut short. You do not need to tune pollReadTimeout unless you have an unusual proxy in front of the API.

Graceful drain

run() installs a SIGTERM/SIGINT handler; stop() (and close()) trigger the same path. On shutdown the worker stops claiming new jobs and waits up to shutdownTimeout for in-flight jobs to finish before forcing the rest down. Jobs that were not yet started are simply left for Flare to redeliver — nothing is lost. Set shutdownTimeout comfortably under your platform's kill grace period (for example a container's termination grace) so the worker drains rather than being hard-killed mid-job.