ben-manes / caffeine / 1965 / 1
94%
master: 100%

LAST BUILD BRANCH: v3.dev
DEFAULT BRANCH: master
Ran
Files 66
Run time 3s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 93.739% (+0.02%) from 93.722%
TERM=dumb

push

travis-ci

ben-manes 
Fix stale notification when eviction raced with an update
[SOLR-10141](https://issues.apache.org/jira/browse/SOLR-10141) (thanks Yonik!)

As an optimization, an update is allowed to bypass the hash map and
synchronize on the read entry directly. In this block it checks
liveliness, perform the mutation, and notifies the writer. This avoids
more expensive computations through the map.

Previously, an eviction was performed in a computation to remove the
entry and notify the writer, or resurrect. Inside the computation the
entry was not synchronized on, and that was done only after it was
removed from the table. The removal listener was notified with the
value initially read at the start of this method.

This allowed an update to modify the value while (or after) the entry
was removing it from the hash table. This led to notifying the writer
and removal listener with the stale value. Because the writer must
be called exclusively with the mutation, this computation must use
a synchronized guard. Otherwise we might have preferred to re-read
the value when notifying the listener. This adds a slight penalty on
eviction (async) while allowing `put` to still be fast (but may block).

`putSlow` was removed as not longer needed. It was a computation-based
write that was safe from this issue. But it was only used when the new
weight was zero, as that update race would cause an incorrect eviction.
Now that the primary path is safe from this race, its unnecessary.

5345 of 5702 relevant lines covered (93.74%)

0.94 hits per line

Source Files on job 1965.1 (TERM=dumb)