I think this fix was reverted for the wrong reason.
ACCUMULO-826 found that a MapReduce job would fail if the process that started the job was killed. This was an issue because we were writing the user's password to a file that was being deleted on exit. Whenever a new map task is kicked off it needs to read the password, so it was trying to read a nonexistent file. But the ranges don't need to be read by each map task, they only need to be accessed once when getSplits is called, which happens before the job is actually submitted. Thus it shouldn't matter if the file containing the ranges is deleted in the middle of a job – if the process exits before the job is actually submitted, the job will fail, but that seems OK to me.
The other issue pointed out in
ACCUMULO-826 is valid, that the file was being written to the file system, added to the distributed cache, then read directly from the file system. The ranges file shouldn't have been added to the distributed cache at all, since it's not needed by the slave nodes.
However, there may be little point in re-applying this fix if the mapred.user.jobconf.limit applies to the whole job submit directory. Using the ranges file method might effectively halve the size of the job submit directory, but you could still hit the limit if you had enough ranges. I guess I'll try to verify this is true. Does anyone have opinions about this issue?