ben-manes / caffeine / 1546
100%

DEFAULT BRANCH: master
Ran
Jobs 1
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
1546

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.

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.

4311 of 4594 relevant lines covered (93.84%)

0.94 hits per line

Jobs
ID Job ID Ran Files Coverage
1 1546.1 (TERM=dumb) 0
93.84
 Travis Job 1546.1
Source Files on build 1546
Detailed source file information is not available for this build.