+1 even JIP lock is removed for aggregating tips counters
> From our cluster, abount 26% of jobtracker's lock taken by the jsp access.
In fact, we decrease lock time by cache getCounters() result. During job is running getCounters are only 1min fresh while it will be completely accurate when job is finished. However this just decrease the invokation for aggregating tips counters and JIP is still in lock when getCounters() is called if the cache is out of 1min.
Maybe we can combine getCounters() cache and no-lock for aggregating tips counters, than both CPU and lock consumptioncan be decreased. Is that OK?