sudheerv commented on pull request #7918: URL: https://github.com/apache/trafficserver/pull/7918#issuecomment-854997424
> A requirements question - should the stats persist across remap reloads? For very long running processes that have many remap reloads, it seems that URL will enter the map but never leave, yielding potential growth without bound. > > If reset on reload is acceptable, why not have an atomic counter in each remap rule structure? The dumper can then grab the current remap configuration and walk it. That object is static and so no locking is required - a remap reload will create an entirely new structure and swap it in. I thought about this, but there are different scenarios to consider here. A remap reload where some old remaps are removed, in those cases agree with you that they remain in the map until a restart. But, the other more common case is adding more remap rules where existing rules remain in the remap.config and their hits may (or may not) be affected due to new ordering. In either case, seems like good data to keep as long as the remap rule remains in the config. Your other suggestion is interesting and will allow to drop the deleted remaps from the counts table. I looked at the data structures, unfortunately the remap rules are organized separately between regular remaps and regex_maps, which means will need to add the counter to two places and update accordingly? The other concern I've is that, we've a huge number of remaps (20K+) and having to duplicate the entire counts table during reload (short window) and make it per thread to avoid concurrency issues, might be a problem? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
