sudheerv commented on pull request #7470: URL: https://github.com/apache/trafficserver/pull/7470#issuecomment-812015996
> > Interesting. Didn't we've a Fuzzy revalidation feature in the ATS core that solves a similar problem (at least for stale objects)? It looks like it's been removed (sorry, I don't have the context as to why), but wonder we should consider reviving that. It feels that it's an arguably better approach as it ensures the object always remains fresh in the Cache and avoids having to fire off 2 parallel requests to the Origin or even block the client request eventually? > > Fuzz had its problems. ATS cache update is not atomic, which makes it harder to implement fuzz properly. This plugin's eventual goal is to eliminate the penalty of origin/client speed while serving a client. This plugin only takes care of eliminating the slow client from the equation. Subsequently, I would like to make cache updates atomic and eventually get to implement fuzzy logic. Ah I see. So, the way I am interpreting this is - 1) With the current approach of firing off 2 parallel requests for a cache fill, the client bandwidth/speed is isolated. But, it has a a drawback of duplicating the Origin traffic. It may be acceptable for some use cases, but, not very sure about use cases such as live streaming. 2) It looks like the eventual plan is to block the client request, complete the cache fill and serve the client from the cache - that removes the extra load on the Origin, but, at that point it looks almost similar to how Fuzzy revalidation worked. As @zwoop pointed in slack, fuzzy may come in handy with open_write_fail_action set to serve stale object while background filling. Worth exploring that. I agree with attempting to make ATS cache updates atomic. -- 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]
