ben-manes / caffeine / 1547 / 1
100%
master: 100%

DEFAULT BRANCH: master
Ran
Files 63
Run time 2s
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.774% (-0.07%) from 93.84%
TERM=dumb

push

travis-ci

ben-manes 
Restore write time on failed refresh

Reviewing refresh after @abatkin's inquiry resulted in a few
observations worth correcting.

A refresh may be scheduled but an explicit write updates the entry
before it starts. In this race the refresh can be cancelled and should
no-op.

A refreh that fails should let the entry expire based on its original
time-to-live. This was being extended by not reverting back the last
write time.

Refresh is documented to not propogate the exception. Instead it should
swallow and log it, as down in LoadingCache#refresh(). The exception
shouldn't reach the executor, which would violate the contract if a
same-thread executor was used.

Because we update the write-time to exclusively trigger a refresh to not
thrash the executor, expire-after-write is not as strict. If the
scheduled refresh is queued by the executor for an excessive time or is
very slow to complete, then the entry may have expired. Currently the
old value is returned, but arguably a load should be triggered instead.
Then either the load or refresh would complete, a fresh value returned,
and the other thread cancelled.

Guava works around this with its custom computation logic based on
futures. Instead of updating the write time, it schedules and checks if
the value is being reloaded. As Java 8's compute isn't future based and
lacks that type of inspection, we would need our own refresh flag per
entry. That is a poor memory trade-off, so this edge case seems not
worth covering. Usually we'd steal the sign bit from the write-time,
but technically System.nanoTime() may return negative values. So this
case is left as wait, see if users complain, and brainstorm how to steal
a bit flag to avoid the waste.

4308 of 4594 relevant lines covered (93.77%)

0.94 hits per line

Source Files on job 1547.1 (TERM=dumb)