I've been asked to explain what exactly the consequence is of TS-2384 and if it causes the cache to be reinitialized.
That is not the case. The background is that the generated cache-lookup *key* is wrong in 4.1.x. This means that the existing objects on the disks will stay in place, but we won't be able to find them, because we are looking in the wrong place. As such we simply store the object again. That's /almost/ the same for people running with a 60 TiB cache, because everything requested is also stored again, and after a while the old objects that have been lying around for a while will be rotated out so that's bad. People with tiny caches or very high turn overs might even notice the downward spike in 304s. The good news is that we have identified the cause[1] real quick and are preparing a fix and regression tests to catch these things in the future. I have also updated the Jira ticket with this explanation. So long, i [1]: https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commitdiff;h=c40c601c9167c4937f972daf7825821e527a5f67 ----- Original Message ----- > > Hey folks. > > I'm sorry to come forward this late into the > release, but we broke it: > > This is a last minute recall of the 4.1.1 release > because we've found a regression that breaks the > cache, or rather key lookup: TS-2384 > > I'll try to put together a post-mortem of this > release attempt, and its teething problems. We're > still convinced that we are on the right track: > > We have found all the major issues early, that is > before the releasing - but still not early enough. > So we'd like to ask you for your continued support. > > Thank you, > > -- Igor > -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: [email protected] URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
