Looking at profiling results, it became clear that the ReduceTask has the following busy-loop which was causing it to suck up 100% of CPU in the fetch phase in some configurations:
- the number of reduce fetcher threads is configured to more than the number of hosts
- therefore "busyEnough()" never returns true
- the "scheduling" portion of the code can't schedule any new fetches, since all of the pending fetches in the mapLocations buffer correspond to hosts that are already being fetched (the hosts are in the uniqueHosts map)
- getCopyResult() immediately returns null, since there are no completed maps.
Hence ReduceTask spins back and forth between trying to schedule things (and failing), and trying to grab completed results (of which there are none), with no waits.