implement aggregate_locking design
[ikiwiki.git] / 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 * load aggregation state
50 * get list of feeds needing aggregation
51 * exit if none
52 * attempt to take aggregation lock, exit if another aggregation is happening
53 * fork a child process to do the aggregation
54   * load wiki state (needed for aggregation to run)
55   * aggregate
56   * lock wiki
57   * reload aggregation state
58   * merge in aggregation state changes
59   * unlock wiki
60 * drop aggregation lock
61 * force rebuild of sourcepages of feeds that were aggregated
62 * exit checkconfig and continue with usual refresh process
63
64 [[done]]