You can bump that up to greater than 5 but just keep in mind that once all parents are tried without success, an additional retry beyond the total number of parents would result in a 502 response back to the client instead of a 404
Sent from my iPhone > On Sep 15, 2022, at 1:58 PM, Robert O Butts <r...@apache.org> wrote: > > Nick, if you're open to writing code, it wouldn't be overly difficult to > modify the parent_select plugin to do what you want. > > https://github.com/apache/trafficserver/tree/master/plugins/experimental/parent_select > https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/parent_select.en.html > https://docs.trafficserver.apache.org/en/latest/admin-guide/files/strategies.yaml.en.html > > >> On Thu, Sep 15, 2022 at 1:55 PM Nick Dunkin <nick.dun...@vecima.com.invalid> >> wrote: >> >> Hi John, >> >> Thanks. >> >> But if I have 5 primary parents in “cluster A”, and 3 secondary parents in >> “cluster B”, then there is no configuration that will get me to “cluster B’ >> if the content is not available (404) on “cluster A”. Which is my problem >> unfortunately. >> >> >> I’d like to push that value of >> >> >> >> #define MAX_SIMPLE_RETRIES 5 >> >> in the code, and rebuild. Any reason that won’t work until I can create a >> more robust solution? >> >> Thanks, >> >> Nick >> >> From: John Rushford <jjrushf...@gmail.com> >> Date: Thursday, September 15, 2022 at 3:40 PM >> To: dev@trafficserver.apache.org <dev@trafficserver.apache.org> >> Subject: Re: Different parent rules for 404 vs 5xx or unavailable >> Yes, max_simple retries should be no more than the total number of parents >> -1. >> >> Let’s say that you have 5 parents and all 5 send back a 404, that’s what >> it should be if none of the parents has the object. However, if you set >> max_simple_retries greater than the total number of parents, the final >> response would be a 502 because all parents were tried and no other parents >> are available. So if you have a total of 5 parents, set max_simple_retries >> to 4, >> Number of parents - 1 >> >> John >> >>> On Sep 15, 2022, at 1:23 PM, Nick Dunkin <nick.dun...@vecima.com.INVALID> >> wrote: >>> >>> Hi John, >>> >>> Thanks for the clarification. >>> >>> My short term mitigation is going to require me to increase the value of >> max_simple_retries. This property is currently fixed in the code to a >> maximum values of 5. Are you aware of any reason that I can’t safely >> increase that maximum (in the code) to something like 8? My 404 responses >> are expected to be very quick, so I’m not too concerned about the >> cumulative timing implications that would occur in this rare failover use >> case. >>> >>> Is there anything special about the upper bound value of 5 for this >> max_simple_retries property? >>> >>> Thanks >>> >>> Nick >>> >>> From: John Rushford <jjrushf...@gmail.com> >>> Date: Thursday, September 15, 2022 at 2:53 PM >>> To: dev@trafficserver.apache.org <dev@trafficserver.apache.org> >>> Subject: Re: Different parent rules for 404 vs 5xx or unavailable >>> Nick, >>> >>> Currently this is not supported a change would have to be made to >> support it. >>> >>> John Rushford >>> jrushf...@apache.org >>> >>> Sent from my iPhone >>> >>>> On Sep 15, 2022, at 10:14 AM, Nick Dunkin <nick.dun...@vecima.com.invalid> >> wrote: >>>> >>>> >>>> Hi, >>>> >>>> I have a parent.config rule that uses a primary and secondary set of >> parents. >>>> >>>> Assuming a 404 from a parent in the primary list I would like to >> immediately try a parent in the secondary parent list, but for a 5xx, or >> connection error, I would like to first exhaust the primary list first, >> before then trying the secondary. >>>> >>>> I would imagine this is a fairly common use case for cluster failover >> behavior. i.e. “Content is HTTP 404 form cluster A, so go to cluster B” >>>> >>>> I am not able to get this use case working with the various options for >> secondary_mode in parent.config (ATS ver 9.1.3). >>>> >>>> Please can anyone provide assistance? Maybe this use case is supported >> with strategies.yaml? >>>> >>>> Thanks >>>> >>>> Nick >>>> >>>> Nick Dunkin >>>> Director, Software Architecture >>>> Manager – Architecture and New Product Introduction >>>> o: +1 678.258.4071 >>>> e: nick.dun...@vecima.com >>>> >>>> >>>> >>
