rackerlabs/blueflood — pull request #175 by fourk (2013-12-13 00:27:46+00:00)
Title: RFR -- fix NPE from calculating courser slots incorrectly

Previously, we would use the timestamp on the UpdateStamp for a given granularity to calculate what courser granularity slots would need to be marked as needing to be (potentially re-)rolled up. We should have been using the original slot to calculate the slot in the courser granularities.

Example:

5m Granularity, slot 1, updated at: t0
20m Granularity, slot 1, updated at: t0+60m

If we called clearFromRunning for the 20m rollup slot 1 with the above state, we would attempt to mark slot 2 of 60m Granularity as needing to be rolled up, because of when 20m slot 1 was last updated. We should not have been determining which slot for 60m based on the updatestamp, but instead on the relative slot (in the example it would be 1).

This slot state stuff gives me a headache trying to coherently express, it probably makes more sense to look at the code changes and ask if you have any questions.

```
Exception in thread "pool-13-thread-3" java.lang.NullPointerException
at com.rackspacecloud.blueflood.service.ShardStateManager.setAllCoarserSlotsDirtyForChildSlot(ShardStateManager.java:123)
at com.rackspacecloud.blueflood.service.ScheduleContext.clearFromRunning(ScheduleContext.java:216)
at com.rackspacecloud.blueflood.service.LocatorFetchRunnable.run(LocatorFetchRunnable.java:148)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
```