Class LuceneIndexManager.Tuning

java.lang.Object
org.frontcache.cache.impl.LuceneIndexManager.Tuning
Enclosing class:
LuceneIndexManager

public static final class LuceneIndexManager.Tuning extends Object
Everything about this index that an operator can tune, in one object so adding a knob does not add a positional constructor argument.

Why commits are no longer per write

indexDoc() used to end in IndexWriter.commit() - a flush plus an fsync of every file in the commit - so every cache miss paid one fsync, and a regular (non-soft) expiry paid two (the removeFromCache delete commits, then the refreshed entry commits). Commit is a checkpoint operation; it belongs on a timer. The durability trade is deliberate. An ungraceful kill now loses up to commitIntervalMs of cache writes instead of at most the one in flight. For a cache that is not a correctness event - the lost entries are simply re-fetched from origin - and LuceneIndexManager.close() commits on ordinary shutdown. Set the interval to 0 to get the old commit-per-write behaviour back.

Why refresh-on-write defaults to true

A cache entry must be visible to the very next request for that URL, or a popular page stampedes the origin for the whole refresh window. So a write refreshes the searcher itself, and the background refresh is only the safety net for the race where two writers overlap (the second maybeRefresh() returns immediately while the first is still refreshing, so the second write can miss that reopen). Turning it off batches writes into fewer, larger segments - better for the merge policy - at the cost of up to refreshIntervalMs of visibility lag.

Note that refresh is much cheaper than the commit it replaced: an NRT reopen flushes, but does not fsync and does not write a new segments file.

  • Constructor Details

    • Tuning

      public Tuning(double maxMergedSegmentMB, double deletesPctAllowed, long commitIntervalMs, boolean refreshOnWrite, long refreshIntervalMs)
  • Method Details