Rules from a previous version of the config file are not a problem, it is duplicate lines in the config file that are, correct? I wonder how you even detect that, other than literal string compares. It does make a bit of an outlier, since it's last match instead of the first match for everything else. For that reason alone I think you should have a command line switch to control the behavior, or something in the config file itself.
On Tue, Nov 17, 2020 at 10:28 AM Olsen, Brian <brian_ols...@comcast.com.invalid> wrote: > This would be during a config reload. It's not uncommon to end up with > the same regex showing up multiple times in that file with different > expiration times. The error made comes from choosing too long a TTL for > the revalidation rule. > > On 11/17/20, 7:40 AM, "Alan Carroll" > <solidwallofc...@verizonmedia.com.INVALID> wrote: > > Is this all in the same configuration? Or duing a config reload? > > On Fri, Nov 13, 2020 at 1:39 PM Olsen, Brian > <brian_ols...@comcast.com.invalid> wrote: > > > Never mind that's too hard to keep track of. The idea here is that > if a > > new regex_revalidate rule comes in with the same regex as an active > but a > > different expiration time it should act as though a new rule came in. > > > > On 11/13/20, 11:59 AM, "Olsen, Brian" <brian_ols...@comcast.com > .INVALID> > > wrote: > > > > For safety's sake it might be best to take the rule expiration > that's > > furthest away (including any already loaded rules) and reset the > > activation/epoch. > > > > On 11/13/20, 10:03 AM, "Sudheer Vinukonda" < > sudheervinuko...@yahoo.com.INVALID> > > wrote: > > > > Sounds reasonable to me. > > Unless, it breaks some backward compatibility that can't be > worked > > around, it feels that this behavior can be made the default (without > any > > need of a config even). > > Thanks! > > Sudheer > > On Friday, November 13, 2020, 08:38:43 AM PST, Olsen, > Brian < > > brian_ols...@comcast.com.invalid> wrote: > > > > Through traffic control we have the limited ability for CDN > > customers to add revalidation requests. Unfortunately there are > times when > > assets need to be revalidated multiple times due to whatever reason. > > > > The way regex_revalidate works now it is first rule wins, > meaning > > that once a rule (regex) is loaded any attempts to reissue that rule > again > > is ignored. > > > > To work better with this self service case I’d like to > propose > > that when regex revalidate sees a new rule with a changed expiration > that > > this new rule’s expiration time becomes the new expiration time and > the > > activation time is reset to this new load time. > > > > I think it would be best to add some parameter to > regex_revalidate > > so that it works in this way. > > > > Any comments? > > > > Thanks! > > > > > > > >
