doc/todo/aggregate_locking.mdwn

   1 The [[plugin/aggregate]] plugin's locking is a suboptimal.
   2
   3 There should be no need to lock the wiki while aggregating -- it's annoying
   4 that long aggregate runs can block edits from happening. However, not
   5 locking would present problems. One is, if an aggregate run is happening,
   6 and the feed is removed, it could continue adding pages for that feed.
   7 Those pages would then become orphaned, and stick around, since the feed
   8 that had created them is gone, and thus there's no indication that they
   9 should be removed.
  10
  11 To fix that, garbage collect any pages that were created by
  12 aggregation once their feed is gone.
  13
  14 Are there other things that could happen while it's aggregating that it
  15 should check for?
  16
  17 Well, things like the feed url etc could change, and it
  18 would have to merge in such changes before saving the aggregation state.
  19 New feeds could also be added, feeds could be moved from one source page to
  20 another.
  21
  22 Merging that feed info seems doable, just re-load the aggregation state
  23 from disk, and set the `message`, `lastupdate`, `numposts`, and `error`
  24 fields to their new values if the feed still exists.
  25
  26 ----
  27
  28 Another part of the mess is that it needs to avoid stacking multiple
  29 aggregate processes up if aggregation is very slow. Currently this is done
  30 by taking the lock in nonblocking mode, and not aggregating if it's locked.
  31 This has various problems, for example a page edit at the right time can
  32 prevent aggregation from happening.
  33
  34 Adding another lock just for aggregation could solve this. Check that lock
  35 (in checkconfig) and exit if another aggregator holds it.
  36
  37 ----
  38
  39 The other part of the mess is that it currently does aggregation in
  40 checkconfig, locking the wiki for that, and loading state, and then
  41 dropping the lock, unloading state, and letting the render happen. Which
  42 reloads state. That state reloading is tricky to do just right.
  43
  44 A simple fix: Move the aggregation to the new 'render' hook. Then state
  45 would be loaded, and there would be no reason to worry about aggregating.
  46
  47 Or aggregation could be kept in checkconfig, like so:
  48
  49 * lock wiki
  50 * load aggregation state
  51 * unlock wiki
  52 * get list of feeds needing aggregation
  53 * exit if none
  54 * attempt to take aggregation lock, exit if another aggregation is happening
  55 * fork a child process to do the aggregation
  56   * lock wiki
  57   * load wiki state (needed for aggregation to run)
  58   * unlock wiki
  59   * aggregate
  60   * lock wiki
  61   * reload aggregation state
  62   * merge in aggregation state changes
  63   * unlock wiki
  64 * drop aggregation lock
  65 * force rebuild of sourcepages of feeds that were aggregated
  66 * exit checkconfig and continue with usual refresh process