alficles commented on pull request #6017: URL: https://github.com/apache/trafficcontrol/pull/6017#issuecomment-879466549
> the race condition is extremely likely to occur, even with a 1-second cache But these things are configurable. If 1s is too long for some users, perhaps it's just right for others. TC doesn't have a strict requirement on polling frequency, different users will have different needs. Someone with a slow TO box will really appreciate having a cache and can adjust queue times appropriately. The race here is not "how long after queuing does a cache poll", though, it's "how long after data modification are updates queued". If you change data, wait 1 second, then queue updates, a cache checking for updates after 1ms will still get the updated data. This is practically only a concern in scripted changes, but scripts can work in concert with the cache duration to ensure no race. If an operator turns on the cache, they might need to add a slight delay between changing data and queuing updates. Alternately, they may need to configure caches to wait a short time after observing an update flag and requesting updates. (As a practical matter, operators currently have challenges with automatic queues because of a huge number of other potential races with data changing on the CDN, but those aren't implicated here.) The operator has all the control they need to optimize the system for their situation, so it's a clear win. Maybe some additional docs on how to use the feature and its implications can make a difference, though. If we wanted to bust the race, though, all we'd have to do is invalidate the cache when updates are queued. That's probably feasible if we want to avoid operators needing to dance around the cache. @rob05c , does that seem feasible? This seems like a clear performance win. There are operational concerns, but it seems to have appropriate controls that allow people to make the right decision for their hardware and operational situation. It supports no-cache requests that allow scripts to ensure no caching. Even a moderately large CDN might see multiple orders of magnitude of performance improvement with very conservative values like just a few milliseconds. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
