The solution is very simple: In the case where the fhc sends out requests to close file handles, the clients might respond very quickly. The fhc will then gather these responses (say, just updates, not closes) and then will sit there for 2 seconds until the timer goes off. Thus the solution is just to subtract the timer period from the calculated average: i.e. the expression is to say 'close file handles that haven't been used for N seconds from NOW' rather than the previous 'close file handles that haven't been used for N seconds from NOW - 2 seconds ago'. This works very nicely and whilst the fhc can get quite busy when there are more users of file handles than there are file handles available, that is hardly surprising, and the fact is starvation is prevented and processes are promptly serviced

1 files changed, 3 insertions, 1 deletions

diff --git a/src/file_handle_cache.erl b/src/file_handle_cache.erl
index e61e9e25..08e71f55 100644
--- a/src/file_handle_cache.erl
+++ b/src/file_handle_cache.erl
@@ -954,7 +954,9 @@ maybe_reduce(State = #fhc_state { limit          = Limit,
                   end, {[], 0, 0}, Elders),
     case Pids of
         [] -> ok;
-        _  -> AverageAge = Sum / ClientCount,
+        _  -> AverageAge =
+                  lists:max([0, ((Sum - (?FILE_HANDLES_CHECK_INTERVAL * 1000))
+                                 / ClientCount)]),
               lists:foreach(
                 fun (Pid) ->
                         case dict:find(Pid, Callbacks) of