Blocking pop

A blocking command does not return immediately on an empty input. It parks the connection on the server until an element arrives or a timeout elapses. Three forms cover the reliable queue:

BLMOVE     wait active RIGHT LEFT 30   # block until wait has an element, then move it; 30s timeout
BRPOPLPUSH wait active 30              # the older blocking move (Redis < 6.2)
BZPOPMIN   marker 30                   # block until the marker ZSET has a member, then pop the lowest

Each parks for up to the timeout. BLMOVE and BRPOPLPUSH block on the work list itself and move an element when one arrives; BZPOPMIN blocks on a sorted set and pops its lowest-scored member. EchoMQ uses the BZPOPMIN form on a marker ZSET — the next dive — but the shape is the same: park, then wake on arrival.

Against the polling loop, the blocking pop removes both costs the interval traded between. There is no poll interval, so a job is picked up the moment it arrives, not up to one interval later — pickup latency is effectively zero. There are no empty round-trips, because the call does not return until there is work or the timeout fires.

# polling: many round-trips, ~½-interval latency
poll → nil → sleep → poll → nil → sleep → … → poll → job

# blocking: one round-trip, ~0 latency
park ─────────────────────────── job arrives → return

The timeout is not a poll interval: it is an upper bound on the park, so the worker can return to re-check its own liveness and is never blocked forever. A short timeout still costs nothing while idle — re-issuing a block is not a busy spin, because the time between blocks is spent parked, not spent sending empty commands.

The block has one price. While a connection is parked on BZPOPMIN, it is busy — a command sent on the same connection waits behind the block until it returns. A worker that blocked on its only connection could not fetch the job, renew a lock, or acknowledge a result while parked. Switch the comparator below to one shared connection and send a command: it queues behind the block. Switch to a dedicated blocking connection and the same command runs at once.

# one shared connection — the block starves the other commands
conn: BZPOPMIN marker 30     # parked…
conn: SET lock …             # …waits behind the block, cannot run

# a dedicated blocking connection — the main connection stays free
block_conn: BZPOPMIN marker 30   # parks here
main_conn:  SET lock …           # runs immediately on the free connection

EchoMQ's worker parks on the dedicated connection by design. EchoMQ.RedisConnection.blocking_connection/1 — documented as "a dedicated blocking connection for operations like BRPOPLPUSH or BZPOPMIN" — hands the worker a connection used only for the block. The blocking-fetch internals EchoMQ.Worker.wait_for_job/2 → do_wait_for_job/3 run the BZPOPMIN emq:{queue}:marker timeout on that connection, and do_wait_for_job/3 returns :job_available when a marker arrived or :timeout when the park elapsed. The worker's main command connection is untouched while it is parked, so it fetches the woken job and runs the rest of the lifecycle without waiting behind the block.

# EchoMQ.Worker.do_wait_for_job/3 — park on the marker ZSET on the blocking connection (real)
case Redix.command(conn, ["BZPOPMIN", marker_key, timeout_seconds], timeout: :infinity) do
  {:ok, nil}                  -> :timeout         # the park elapsed, no job
  {:ok, [_key, _member, _sc]} -> :job_available   # a marker arrived → a job is available
end

The three blocking pops behind the wait — the modern move, its older form, and the marker pop EchoMQ parks on — and the queue protocol that runs them on a dedicated connection.