Nick, Yes, it happens on the same continuation. If there is a connection cannot be opened to the upstream endpoint, the parent is marked down and the next available parent on the consistent hash ring is then tried (no rehashing, just next available).
Now when we say marked down, there is a threshold that must be crossed before a parent is made unavailable, see proxy.config.http.parent_proxy.fail_threshold and set that accordingly. Once the parent has been made unavailable, there is a retry window, see proxy.config.http.parent_proxy.retry_time and once the window has been reached, the parent is made available for retrying. If it's retried on the next transaction and that retry is successful, the parent is marked up. If the retry fails, it is marked unavailable until the window again expires for retry. John Rushford jrushf...@apache.org On Tue, Aug 17, 2021 at 9:40 AM Nick Dunkin <nick.dun...@vecima.com.invalid> wrote: > Hi, > > > > I have a question about Consistent Hash behavior when a parent is “down”. > This is ATS 7.1 > > > > The documentation states the following: “*If a parent is down, the > traffic that would go to the down parent is rehashed amongst the remaining > parents. The other traffic is unaffected. Once the downed parent becomes > available, the traffic distribution returns to the pre-down state.*” > > > > That second section implies that maybe: > > - A background thread is periodically retying the original hashed > parent, in order to mark it back *up* > - The original hashed parent is being retried on every access until it > is available again > > > > Please can someone clarify the exact behavior around Consistent Hash and > unavailable parents? The context here is that we believe we are seeing the > retries on the originally hashed parent occur more often than we would > expect. > > > > Many thanks, > > > > Nick > > > > *Nick Dunkin* > > Director, Software Engineering > > Manager – Architecture and New Product Introduction > > *o: * *+1 678.258.4071* > > *e:* nick.dun...@vecima.com > > > > [image: cidimage001.png@01D6CC8C.6FC5A580] > > > -- John Rushford jjrushf...@gmail.com
