Obviously, it is going to be slower to pull regex_revalidate.config thru TO as opposed to pulling it off the file system. The question is...is this acceptable?
curling to https://to.domain.com/Trafficserver-Snapshots/cdn-name/regex_revalidate.config time_namelookup: 0.005 time_connect: 0.058 time_appconnect: 0.000 time_pretransfer: 0.000 time_redirect: 0.000 time_starttransfer: 0.000 ---------- time_total: 0.063 curling to https://to.domain.com/genfiles/view/server-host-name/regex_revalidate.config time_namelookup: 0.005 time_connect: 0.062 time_appconnect: 0.307 time_pretransfer: 0.307 time_redirect: 0.000 time_starttransfer: 0.781 ---------- time_total: 0.781 On Mon, Dec 12, 2016 at 9:03 PM, Steve Malenfant <[email protected]> wrote: > I'm OK with this. I think most of the revalidate functionality is not well > understood here... I guess I need to look into the API since we are using > the UI to issue revalidate today. > > On Mon, Dec 12, 2016 at 5:43 PM, Jeremy Mitchell <[email protected]> > wrote: > > > I've created an issue to solicit some feedback regarding the removal of > > regex_revalidate.config from the file system. If you are not aware, > > regex_revalidate.config is the ATS config file used to "invalidate > > content". Storing regex_revalidate.config on the file system makes it > > harder to set up a highly-available, redundant traffic ops. > > > > https://issues.apache.org/jira/browse/TC-68 > > > > Thanks! > > >
