echd — Echo on Encore · E3.3 · dive
Batches and Locks
A batch is claimed together and settled apart — many jobs in one round trip, their leases renewed as one, but each finished on its own verdict, so one poison job never drags its batch down.
echd speaks in the present tense over a build ladder. Every module, verb, key, and port named on this page is real; the composition into one standing platform is the vision the ladder builds.
The dive
docs/echo_mq/specs/emq2/emq.5/emq.5.md · specs/emq.commands/emq.commands.mdClaiming one job at a time is correct but slow: every claim is a round trip. @bclaim claims a whole batch in a single move — claim_batch/4 and the BatchConsumer shape it by a min_size and a timeout, and @gbclaim keeps a batch inside one group's lane — so throughput rises without loosening the lease discipline that protects each job. A batch is not a looser claim; it is many claims made at once.
The word lock on this bus is not a separate primitive — the lock is the lease. A claimed job is locked to its worker for the duration of its lease; extendLock renews one, extendLocks renews a whole batch together, releaseLock frees it, and a stalled-job sweep reclaims the locks of a worker that died. That pairing is what makes batches safe: the batch holds many locks and renews them as one, so a slow run keeps its whole batch, and yet the partitioned finish settles each job on its own verdict — these acked, those returned to retry — so one poison job in a batch of fifty never drags the other forty-nine back.
Claimed together, settled apart
docs/echo_mq/specs/emq2/emq.5/emq.5.md@bclaim takes a whole batch of jobs in a single round trip — claim_batch/4 and the BatchConsumer shape it by min_size and a timeout, and @gbclaim keeps a batch within one group's lane. Fewer round trips, more throughput, the same lease discipline per job.extendLock renews one, extendLocks renews a whole batch at once, and releaseLock frees it. Nothing is a separate mutex — holding the job is holding the lock — and a stalled-job sweep reclaims the locks of a worker that died.Hover or focus a part to read it; click to pin. Without scripting, all three read in sequence.
The tension the batch resolves
docs/echo_mq/specs/emq2/emq.5/emq.5.md · specs/emq.commands/emq.commands.mdA batch has to hold two things that pull against each other: efficiency wants the jobs treated as one, correctness wants them treated as many. Treat them purely as one — claim, run, ack the lump — and a single bad job fails the whole batch, forcing fifty retries for one fault. Treat them purely as many — a round trip each — and the throughput win is gone. The bus keeps both by splitting the join along the right seam: claimed together, locked together, settled apart.
The lease is where "together" lives. @bclaim takes the batch atomically, and extendLocks renews every lease in it in one move, so a batch that runs long does not lose a job to an expired lock halfway through. The verdict is where "apart" lives. EchoMQ.BatchFinish carries a per-member result, so the finish acks the jobs that succeeded and returns the ones that failed to retry, each on its own attempts clock. The stalled-job sweep backs the whole thing: if the worker dies holding the batch, its locks are reclaimed and the jobs return to be claimed again. Bulk where bulk is safe, individual where individuality matters.
The rule
one line to carryThe batch rule — a batch is claimed together and settled apart: many locks renewed as one, verdicts rendered per item. @bclaim takes many in one round trip and extendLocks renews their leases together, but the partitioned finish acks and retries each on its own — so one poison job never drags its batch down, and a dead worker's locks are reclaimed for the whole batch.
Doors
batches and locks, in depthEchoMQ — the protocol, in depth
@bclaim, claim_batch, @gbclaim, BatchFinish, and the lock family — extendLock, extendLocks, releaseLock — in full.
the batch, command by command — claim, renew, finish, reclaim.
/redis-patternsRedis Patterns, Applied
Bulk consumption and lease management as patterns: pipelined claims, batch renewal, and per-item completion.
one round trip, many jobs — why batching wins, and where it must not.
References
sources · relatedSources
- Valkey — Pipeliningwhy claiming and renewing many jobs in one round trip beats one at a time
Related
- E3.3 — Jobs Supersede Cron and Queuesthe module this dive closes
- fair-lanes-and-the-metronomethe rule before this one: the claim and the lease this batch renews
- E3 — The Bus — EchoMQ Supersedesthe supersessions the job system delivers