Sets the four handler queue capacities (asHandlerQueueSize, peerHandlerQueueSize, prefixHandlerQueueSize, peeringHandlerQueueSize in internal/routewatch) from 100,000 to 20,000, about four seconds of feed at peak. A message pointer is retained until the slowest handler drains it, so all four full was a derived worst case near 800 MiB; the new bound caps that near 160 MiB. The streamer already drops rather than blocks on a full queue, so the smaller capacity only changes how many messages are dropped under load, never correctness.
Batch sizes are unchanged, as the issue requires. The largest, asnBatchSize, is 30,000 and now exceeds its queue. This does not stall flushing: each handler runs a flush-loop goroutine that flushes on its own timer regardless of how full the batch is (asnBatchTimeout and peerBatchTimeout 2s, prefixBatchTimeout 1s, and the peering handler on its process interval). A batch can also still reach 30,000 because one queued UPDATE contributes every ASN in its path, not one entry.
Comments beside each constant are updated to state the new size and why it is safe. No README text quoted the old figure; the only other 100000 in the tree is an unrelated AS-count assertion in pkg/asinfo.
TODO.md is not touched, consistent with the other memory-reduction units, which track their work on issue 3 rather than in TODO.md.
Model: opus-4-8
Part of https://git.eeqj.de/sneak/routewatch/issues/3, unit U5. Implements https://git.eeqj.de/sneak/routewatch/issues/11.
Sets the four handler queue capacities (`asHandlerQueueSize`, `peerHandlerQueueSize`, `prefixHandlerQueueSize`, `peeringHandlerQueueSize` in `internal/routewatch`) from 100,000 to 20,000, about four seconds of feed at peak. A message pointer is retained until the slowest handler drains it, so all four full was a derived worst case near 800 MiB; the new bound caps that near 160 MiB. The streamer already drops rather than blocks on a full queue, so the smaller capacity only changes how many messages are dropped under load, never correctness.
Batch sizes are unchanged, as the issue requires. The largest, `asnBatchSize`, is 30,000 and now exceeds its queue. This does not stall flushing: each handler runs a flush-loop goroutine that flushes on its own timer regardless of how full the batch is (`asnBatchTimeout` and `peerBatchTimeout` 2s, `prefixBatchTimeout` 1s, and the peering handler on its process interval). A batch can also still reach 30,000 because one queued UPDATE contributes every ASN in its path, not one entry.
Comments beside each constant are updated to state the new size and why it is safe. No README text quoted the old figure; the only other 100000 in the tree is an unrelated AS-count assertion in `pkg/asinfo`.
`TODO.md` is not touched, consistent with the other memory-reduction units, which track their work on issue 3 rather than in `TODO.md`.
Model: opus-4-8
Created in error by a mis-sent API request; not a real issue. The work is #11, implemented in #21. Closing.
Model: opus-4-8
Created in error by a mis-sent API request; not a real issue. The work is https://git.eeqj.de/sneak/routewatch/issues/11, implemented in https://git.eeqj.de/sneak/routewatch/pulls/21. Closing.
Model: opus-4-8
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.
Part of #3, unit U5. Implements #11.
Sets the four handler queue capacities (
asHandlerQueueSize,peerHandlerQueueSize,prefixHandlerQueueSize,peeringHandlerQueueSizeininternal/routewatch) from 100,000 to 20,000, about four seconds of feed at peak. A message pointer is retained until the slowest handler drains it, so all four full was a derived worst case near 800 MiB; the new bound caps that near 160 MiB. The streamer already drops rather than blocks on a full queue, so the smaller capacity only changes how many messages are dropped under load, never correctness.Batch sizes are unchanged, as the issue requires. The largest,
asnBatchSize, is 30,000 and now exceeds its queue. This does not stall flushing: each handler runs a flush-loop goroutine that flushes on its own timer regardless of how full the batch is (asnBatchTimeoutandpeerBatchTimeout2s,prefixBatchTimeout1s, and the peering handler on its process interval). A batch can also still reach 30,000 because one queued UPDATE contributes every ASN in its path, not one entry.Comments beside each constant are updated to state the new size and why it is safe. No README text quoted the old figure; the only other 100000 in the tree is an unrelated AS-count assertion in
pkg/asinfo.TODO.mdis not touched, consistent with the other memory-reduction units, which track their work on issue 3 rather than inTODO.md.Model: opus-4-8
Created in error by a mis-sent API request; not a real issue. The work is #11, implemented in #21. Closing.
Model: opus-4-8