RFR: 8330077: Allow max number of events to be buffered to be configurable to avoid OVERFLOW_EVENT [v2]

Fabian Meumertzheim duke at openjdk.org
Fri Apr 12 10:08:43 UTC 2024


On Fri, 12 Apr 2024 09:41:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> It you are reacting to the OVERFLOW events already, I doubt we need to get to Integer.MAX_VALUE. Maybe all that's needed is something large enough to reduce the frequency of OVERFLOW events. I don't have any insight into that.
>> 
>> I searched for usage reports and found users trying to watch "billions" of files at a time. Given that the actual limit is still user-configurable and the default remains at 512, I'm not sure whether there is any reasonable hard limit I could come up with that doesn't unnecessarily restrict users. After all, *if* a user sets this limit so high that they run into e.g. memory issues due to a large event list, wouldn't we consider them responsible for this?
>> 
>> In lieu of an actual upper bound I could justify, I went with `ArraySupport.SOFT_MAX_ARRAY_LENGTH` for now so that an OVERFLOW event is likely to. be sent before the list OOMs when trying to grow.
>
> The proposed change looks overly complicated. If the property is set to garbage or a numeric value < 1 then there may be an argument to use the default but it seems very strange to disallow setting it to a value such as 128.

I'm fully open to changing it so that the default is only used if `intValue <= 0`. 

An argument I could see in favor of enforcing a minimum of 512 is backwards compatibility: It's possible that there are applications out there relying on being able to receive at least 512 file system events without an (automatic) OVERFLOW. If users of those applications set a lower limit, this could result in subtle thrashing issues that may not be directly attributable to this setting. 

But this is just theory and I'm not sure what the right balance between this concern and simplicity is. @AlanBateman Curious to hear your thoughts on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1562342768


More information about the nio-dev mailing list