tim-group/Tucker — pull request #8 by Grundlefleck (2014-08-06 16:38:41+00:00)
Title: Async checking take 2

Second pass at out-of-the-box support for wrapping normal components to update asynchronously. Points of note:

* introduced `AsyncComponentScheduler` to hold a single scheduled executor instead of having an executor for each `AsyncComponent`. I realised my entire motivation for having one executor per `AsyncComponent` is a misunderstaning of `ScheduledExecutorService#scheduleWithFixedDelay`, which will ensure that a given runnable is running at most once at any time, and will reschedule after it completes.
* pushed the interface pulled out of `StatusPageGenerator` back down, so there's only one implementation. A `StatusPageGenerator` should be used as normal, and components registered like so: `myAsyncComponentScheduler.addComponentsTo(myStatusPageGenerator);`
* hardcoded to kick off the first component update immediately
* before the first component returns, the component will be WARNING, not INFO
* made it easier to create async components from a list of normal, synchronous components, with sensible-ish defaults, like so: `AsyncComponentScheduler.createFromSynchronous(myListOfNormalComponents);`. Most of the settings are overrideable with a different instance of AsyncSettings, which replaces the earlier Builder approach.
* wrapped two `AtomicRef` fields into a composite object. A race condition still exists, but I'm happy that the guarantees offered by the `ScheduledExecutorService` make it a non-issue.
* the `ScheduledThreadExecutor` will also grow threads as necessary, with sensibly named threads

Merging for now, but happy for further bikeshedding.