Re: Handling requests to an upstream that is unresponsive.

Miles mentioned at the summit that this should check "serve stale while error" before sending 503. On Wed, Oct 2, 2019 at 1:47 PM Alan Carroll wrote: > You need to talk to the L7R group at the summit. What does it do if no > upstream is available? That's the actual issue my change would address.

Re: Handling requests to an upstream that is unresponsive.

You need to talk to the L7R group at the summit. What does it do if no upstream is available? That's the actual issue my change would address. I do think we should either make this change, or simply remove support for handling dead upstrreams - the current implementation is worse than useless IMHO.

Re: Handling requests to an upstream that is unresponsive.

Yes, as a supplement for what Sudheer pointed out, on LI Traffic's roadmap, we're adopting dynamic-discovery (D2), a client-side load-balancing strategy that can gracefully solve the issue. If some origin servers are

Re: Handling requests to an upstream that is unresponsive.

+1 on the problem :) We’ve often had very similar production issues too! A related issue here that plays a role in all of this mechanism is server session pools and the fact that ATS only marks a server down on a “connect failure”. In particular, when ATS tries to reuse an existing idle connec

Handling requests to an upstream that is unresponsive.

I would like to propose a change to how TS handles unresponsive upstream destinations. The current logic is * If there is a round robin, skip elements that are down. * Attempt to connect. * If the connect fails, and the upstream is marked down and within the down server cache time, restrict the