8.4 LRU

(require web-server/managers/lru)

"managers/lru.ss" defines a manager constructor:

(create-LRU-manager   instance-expiration-handler             check-interval             collect-interval             collect?            [ #:initial-count initial-count             #:inform-p inform-p])   →   manager?

instance-expiration-handler : expiration-handler?

check-interval : integer?

collect-interval : integer?

collect? : (-> boolean?)

initial-count : integer? = 1

inform-p : (integer? . -> . void) = (lambda _ (void))

Instances managed by this manager will be expired if there are no continuations associated with them, after the instance is unlocked. If an expired instance is looked up, the exn:fail:servlet-manager:no-instance exception is thrown with instance-exp-handler as the expiration handler.

Continuations managed by this manager are given a "Life Count" of initial-count initially. If an expired continuation is looked up, the exn:fail:servlet-manager:no-continuation exception is thrown with instance-exp-handler as the expiration handler, if no expiration-handler was passed to continuation-store!.

Every check-interval seconds collect? is called to determine if the collection routine should be run. Every collect-interval seconds the collection routine is run.

Every time the collection routine runs, the "Life Count" of every continuation is decremented by 1. If a continuation’s count reaches 0, it is expired. The inform-p function is called if any continuations are expired, with the number of continuations expired.

The recommended use of this manager is to pass, as collect?, a function that checks the memory usage of the system, through current-memory-use. Then, collect-interval should be sufficiently large compared to check-interval. This way, if the load on the server spikes – as indicated by memory usage – the server will quickly expire continuations, until the memory is back under control. If the load stays low, it will still efficiently expire old continuations.

With Continue (http://continue.cs.brown.edu/), we went from needing to restart the server a few times a week and having many complaints under load, to not having these complaints and not needing to restart the server for performance reasons.