Reconnect when RIS Live ends or stalls the stream (closes #53)
check / check (push) Waiting to run
check / check (push) Waiting to run
When RIS Live ended the response normally, the reconnect loop stopped for good and the health check kept reporting the feed connected; a connection that stayed open but sent nothing blocked forever. Now only `Stop` ends the loop: any other end clears the connected flag and reconnects with the existing backoff. If no line arrives for 60 seconds, including while waiting for RIS Live to answer the request, the streamer drops the connection and reconnects. Tests use a local fake server. README "Reconnection" describes both. Model: opus-5-5
This commit was merged in pull request #60.
This commit is contained in:
@@ -141,7 +141,10 @@ routewatch/
|
||||
- **Batched Writes**: All database operations are batched for performance
|
||||
- **Backpressure**: Probabilistic message dropping when queues exceed 50% capacity
|
||||
- **Graceful Shutdown**: 60-second timeout, flushes all pending batches
|
||||
- **Reconnection**: Exponential backoff (5s-320s) with reset after 30s of stable connection
|
||||
- **Reconnection**: Any end of the stream other than shutdown, including RIS Live
|
||||
ending the response normally, marks the feed disconnected and reconnects with
|
||||
exponential backoff (5s-320s). The backoff resets after a stream that lasted
|
||||
more than 30s. A stream with no line for 60s is dropped and reconnected.
|
||||
- **IP Lookup**: the most specific live route is found by looking up the
|
||||
address's prefix at each mask length, longest first, in the prefix index
|
||||
(at most 25 lookups for IPv4, 113 for IPv6); prefixes are stored in the
|
||||
|
||||
Reference in New Issue
Block a user