Shutdown now writes the updates still in the handler queues
(#69).
Shutdown stops the streamer first, then the four handlers, each writing
what it holds.
Streamer.Stop puts the STATE messages it holds for a full queue on that
queue, after what is already there. It then closes the queues and returns
once every worker has handed its handler everything on its queue.
PeeringHandler.Stop waits for its loop's final write, as the other handlers
do. Before, it ran a second write alongside that one.
Not visible in the diff:
Stop holds the streamer's lock while a held message waits for room. The
workers do not take that lock. The status page's handler statistics wait
that long.
Draining is in-memory work, at most 20,000 messages per queue. A handler at
its batch ceiling waits for the write in progress, which its Stop already
waited for. The final writes grow by what was queued. I added no separate
time bound: shutdown stays inside the 60-second limit unless one batch write
takes most of it, as before.
Disclosures:
Deviation: new Streamer.SetURL, used only by the shutdown test to read from
a local server.
TestStopReturnsAtOnceWithStateMessagesHeld is now TestStopQueuesTheHeldStateMessages: with nothing taking from the queue, the
old test would hang.
On the old code, the peering handler test fails only when the loop wins the
race for the paths.
Unverified: how long the larger final writes take on the live feed, measured
against docker stop's wait.
Model: opus-5-5
Shutdown now writes the updates still in the handler queues
(https://git.eeqj.de/sneak/routewatch/issues/69).
- `Shutdown` stops the streamer first, then the four handlers, each writing
what it holds.
- `Streamer.Stop` puts the `STATE` messages it holds for a full queue on that
queue, after what is already there. It then closes the queues and returns
once every worker has handed its handler everything on its queue.
- `PeeringHandler.Stop` waits for its loop's final write, as the other handlers
do. Before, it ran a second write alongside that one.
Not visible in the diff:
- `Stop` holds the streamer's lock while a held message waits for room. The
workers do not take that lock. The status page's handler statistics wait
that long.
- Draining is in-memory work, at most 20,000 messages per queue. A handler at
its batch ceiling waits for the write in progress, which its `Stop` already
waited for. The final writes grow by what was queued. I added no separate
time bound: shutdown stays inside the 60-second limit unless one batch write
takes most of it, as before.
Disclosures:
- Deviation: new `Streamer.SetURL`, used only by the shutdown test to read from
a local server.
- `TestStopReturnsAtOnceWithStateMessagesHeld` is now
`TestStopQueuesTheHeldStateMessages`: with nothing taking from the queue, the
old test would hang.
- On the old code, the peering handler test fails only when the loop wins the
race for the paths.
- Unverified: how long the larger final writes take on the live feed, measured
against `docker stop`'s wait.
Model: opus-5-5
Shutdown stopped the handlers before the streamer, so the updates still
on the handler queues reached handlers that no longer wrote them. It now
stops the streamer first. Streamer.Stop puts the STATE messages it holds
for a full queue on that queue, closes the queues and returns once every
worker has handed its handler everything on its queue; then each handler
writes what it holds. PeeringHandler.Stop now waits for its loop's final
write instead of racing it.
Streamer.SetURL lets the shutdown test read from a local server.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Shutdown now writes the updates still in the handler queues
(#69).
Shutdownstops the streamer first, then the four handlers, each writingwhat it holds.
Streamer.Stopputs theSTATEmessages it holds for a full queue on thatqueue, after what is already there. It then closes the queues and returns
once every worker has handed its handler everything on its queue.
PeeringHandler.Stopwaits for its loop's final write, as the other handlersdo. Before, it ran a second write alongside that one.
Not visible in the diff:
Stopholds the streamer's lock while a held message waits for room. Theworkers do not take that lock. The status page's handler statistics wait
that long.
its batch ceiling waits for the write in progress, which its
Stopalreadywaited for. The final writes grow by what was queued. I added no separate
time bound: shutdown stays inside the 60-second limit unless one batch write
takes most of it, as before.
Disclosures:
Streamer.SetURL, used only by the shutdown test to read froma local server.
TestStopReturnsAtOnceWithStateMessagesHeldis nowTestStopQueuesTheHeldStateMessages: with nothing taking from the queue, theold test would hang.
race for the paths.
against
docker stop's wait.Model: opus-5-5
Review passed.
Model: opus-5-5