Tags: aping-fo/caffeine
Tags
Add Coverity build scan Fixed minor compilation errors in their static analysis. But the plugin assumes a commercial installation for local analysis. The open-source portal doesn't seem to accept the emit-db due to not having a build-log.txt file. So more debugging is required to figure out how to integrate with Coverity Scan. Despite that, merging since the changes were benign and we might get it working in the future.
Update shaded JCTools queue due to live-lock (fixes ben-manes#127) In ben-manes#127, a live-lock occurs in the write buffer due to a race when the consumer tries to transition to the last buffer. This is a shaded copy of JCTools' MpscGrowableLinkedArrayQueue and fixed in 2.0 (see JCTools/JCTools#135). This is a difficult to reproduce bug, except for the reporter due to having thousands of instances on a loaded system. The shaded copy is more verbose than the previous one, but that is to minimize the divergency and introducing bugs by cutting too deep. Updating to Guava 20 required minor changes due to that cache now supporting write-through entries. The adapter now mirrors the new behavior. Thanks to everyones patience and help in fixing the bug.
Pluggable JCache Factory for dependency injectors (fixes ben-manes#117)
Fix reference cache triggering maintenance after a write (fixed ben-m… …anes#111) This oversight caused write methods to not try to clean-up collected entries for caching using only the weak/soft reference configurations. The maintenance would be triggered after enough reads or if manually calling cleanUp(). Most of the changes are improvements to the unit tests, as test flaws allowed this bug to be introduced. Primarily the cause was due to not being strict enough when evaluating the removal notifications. The tests now highlight a slight difference in Guava & Caffeine regarding if replacing a value with the same instance triggers a notification. Other small mistakes in the reference cache tests were uncovered and fixed.
Assist maintenance task when executor is exhausted (fixes ben-manes#90) The write buffer is used to allow writers to update the eviction policy in a non-blocking manner. The maintenance work is delegated to an async task when possible to minimize request latencies. Previous iterations (Guava, CLHM) amortized it on the calling thread due to not having a system-wide executor to take advantage of. Previously when the write buffer was full the writing threads would spin, yield, and wait for the maintenance task to catch up. This was under the assumption that the task was running but starved out due to synthetic load testing, e.g. running `cache.put` with more threads than cores. The belief was that the write buffer would be full under normal usage and the maintenance task would be scheduled promptly. This assumption fails for workloads where every worker in the executor is updating the cache. This can happen in a synthetic refresh test, but also with an AsyncLoadingCache when futures complete. In that case the maintenance task is scheduled but unable to run, and all of the worker threads are spinnining endlessly trying to append to the write buffer. In this case we degrade to amortize the maintenance work on the caller. This allows progress to be made, avoids wasteful busy waiting, and should not increase the response penalty in most cases. That is because writers would have had to wait anyway and this would typically happen only on asynchronous non-user facing tasks (completers, refresh). This also removes the ugly Thread.yield() hack, which did look unnatural. Thanks goes to @DougLea for identifying the oversight that the executor may exhaust its threads, causing this problem.
CASSANDRA-11452: Stronger resistence to hash collision attacks Thanks to further discussions with the Cassandra and TinyLFU folks, this is a fairly strong guard against the collision attack. This also has very low overhead and impact to existing hit rates. The previous commit was fairly weak in comparison. We concluded that some randomness was desirable in either the admission or eviction policy. A few of the better options were simulated and this is my favorite balance. It might change when Roy presents his feedback from pondering it on his long flight home. The attack requires that the victim be pinned to an artifically high frequency due to a hash collision, so that no entries are admitted. When a warm candidate is rejected by the frequency filter, we give it a 1% chance of being accepted anyway. This kicks out the attacker's victim and protects well against her having multiple collisions in her arsenal. In small and large traces it is rarely triggered due to normal usage, and does not admit too frequency to hurt the hit rate. The other attack vector is the sketch's hash functions. This is already protected with a random seed. We now protect against the weak 32-bit hash codes used by Java.
PreviousNext