Why does a long-poll server answer empty-handed when its own hold period expires instead of waiting indefinitely?

The hold period is the one number a long-poll server owns, and almost every operational problem with the technique is that number sitting in the wrong place relative to two others. ## Why the hold is bounded at all An unanswered request is silence, and silence has too many causes. - **The client cannot read it.** No response means either nothing was published or the path is broken; from the client's side those look identical. - **The server cannot read it either.** A client that has been powered off leaves a parked request behind that looks exactly like an attentive one until something is written to it. - **Resources accumulate.** Every parked request holds a registration, a buffer and whatever runtime resource the request occupies; without a bound, the population only ever grows. - **Things on the path have their own opinions.** Intermediaries impose idle limits on connections carrying no bytes, and they enforce them whether or not your server is willing to keep waiting. Answering with an empty result solves all four at once: it frees the request, refreshes both sides' evidence that the other is alive, and does it on the server's schedule rather than an intermediary's. ## Order the three deadlines These are three different timeouts with three different owners, and the order between them is the whole design: 1. **The server's hold period** — how long it parks a request with nothing to say. 2. **The client's read timeout** — how long the client waits for a response before giving up on the request. 3. **The shortest idle limit on the path** — how long anything between them tolerates a connection carrying no bytes. The rule is `hold period < read timeout` and `hold period < shortest idle limit`, with margin on both. Get either backwards and the technique still appears to work, at a cost you only see in the logs. | ordering | what you observe | |---|---| | hold longer than the client's read timeout | every cycle ends as a client-side abort; the server writes its answer into a request nobody is reading, and the event it carried is the one the client never sees | | hold longer than an intermediary's idle limit | the request dies with no status line and no body; the client sees a transport error and cannot tell an empty result from a failure | | hold far shorter than the path allows | the technique still works, but the idle exchange rate climbs toward short polling's without buying the freshness | | hold correctly ordered | quiet periods produce one empty answer per hold per client, and publishes go out about a round trip after they happen | ## What the empty answer costs The bound puts a floor under idle traffic: `clients / hold period` exchanges per second regardless of activity. At a 45-second hold, 5,000 devices generate roughly 110 exchanges a second doing nothing at all. That is far below a tight short poll, and it is not zero — which is why the hold length is an economic choice and not just a safety one. ## Choosing the number - Start below the shortest idle limit you can actually observe on the path, with margin for a slow answer. - Keep it comfortably under the client's read timeout, and set that read timeout deliberately rather than inheriting a default nobody chose. - Make it long enough that the idle exchange rate is affordable at fleet scale. - Make the empty answer explicit — a normal successful response carrying an empty event list and the client's current position — so the client can tell it apart from a failure without guessing. ## What the client does with it It re-issues immediately, with the same position it sent before. An empty answer at hold expiry is the normal cycle, not an error, so there is nothing to recover from and nothing to slow down for. Clients that treat it as a failure — and back away from the server for it — turn a healthy quiet period into a growing delay on the first real update. The distinction to hold onto is that the *server's hold period* and the *client's poll interval* are different things owned by different sides: long polling replaces the interval with the hold, and a design that keeps both is usually one that has not decided which technique it is using.