• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

ben-manes / caffeine / 2409
100%

Build:
DEFAULT BRANCH: master
Ran 03 Aug 2019 03:56AM UTC
Jobs 1
Files 76
Run time 8s
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

pending completion
2409

push

travis-ci

ben-manes
Support prompt expiration via an optional scheduler thread (fixes #195)

Typically the cache using an amortized maintenance routine to periodically
keep the eviction policies up to date. For size this is to replay hits or
evict, for expiration this is to discover stale entries, and for reference
caching this is to find GC'd keys or values. Each policy uses O(1)
algorithms to be cheap, batches the work to avoid lock contention, and
performs this routine maintenance as a side effect of normal cache
operations.

If there is no activity on the cache then the routine maintenance is not
triggered, as that requires a background scheduling thread. Generally this
is okay as the memory was already in consumed, no activity may indicate low
system usage, and the cache is a transient data store. However, some do want
to trigger business logic and leverage the cache as a timing subsystem, e.g.
using the `RemovalListener` to notify another component.

The cache itself does not create or manage threads, but can defer work to
a configured `Executor`. Similarly now it can now schedule the maintenance
routine on a configured `Scheduler`, default disabled. The cache will still
perform maintenance periodically and this scheduler only augments it to add
additional liveliness. The scheduling is based on the expiration time only;
users may use `Cache.cleanUp()` for fixed periods to assist reference
caching, etc as desired.

The cache will rate limit the scheduler so that it runs at a reasonable pace
and never thrashes. For example, if the next expiration times are tiny
durations apart (e.g. 200ms), the cache will not run the maintenance task
5x/s. It will instead ensure a 1 second delay (2^30ns) between scheduled runs
(not accounting for the lack of real-time guarantees by a Scheduler impl).
Similarly an additional delay may occur due to the priority queues being held
in best-effort order.

The scheduling for variable expiration is based on the TimerWheel's bucket
expiration... (continued)

6105 of 6516 relevant lines covered (93.69%)

0.94 hits per line

Jobs
ID Job ID Ran Files Coverage
3 2409.3 (GROUP=tests) 03 Aug 2019 03:56AM UTC 0
93.69
Travis Job 2409.3
Source Files on build 2409
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #2409
  • e4d55348 on github
  • Prev Build on master (#2408)
  • Next Build on master (#2411)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc