Fwd: Making AbstractWatchKey#MAX_EVENT_LIST_SIZE tunable

[Fabian Meumertzheim]

(forwarding for posterity as I didn't reply all)

Hi Brian,

I filed an enhancement issue with internal review ID 9076868.

I would consider introducing a system property that, if set, is used to
populate the limit, with the default remaining at 512. This is because:
* File system watching often already requires user configuration (e.g.
bumping the default inotify limits on Linux).
* The end user of a JVM-based application knows which scale they operate
the application on and what the IO/CPU capabilities of the machine running
the application are.

An alternative could be to make this configurable on a per-WatchService
basis, but that would also require code changes before end users get to
benefit from the ability to increase the limit.

(This is my first enhancement request, so I apologize for not knowing the
processes that well. Thanks for the link!)

Best,
Fabian

On Wed, Apr 10, 2024 at 6:07 PM Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Hello Fabian,
>
> Do you have any idea of how you might want to implement this or of how we
> might do it if we were to pick up the task? In any case, an enhancement
> issue should be filed [1].
>
> Thanks,
>
> Brian
>
> [1] https://openjdk.org/guide/#filing-an-issue
>
> On Apr 10, 2024, at 8:35 AM, Fabian Meumertzheim <fabian at buildbuddy.io>
> wrote:
>
> When using WatchService to watch a directory, the
> AbstractWatchKey#MAX_EVENT_LIST_SIZE constant (value: 512) makes it so that
> e.g. creating 1000 files in a single watched directory inevitably results
> in an OVERFLOW event.
>
> The build system Bazel (https://github.com/bazelbuild/bazel) relies on
> the JVM's WatchService mechanism for all its file system watches on Linux.
> Since many Bazel users work with big monorepos, they tend to get into
> situations where switching Git branches causes the hard-coded limit to be
> hit frequently.
>
> The constant comes with a comment saying "(in the future this may be
> tunable)". Would a contribution be welcome that makes this limit tunable
> via a system property (or some other mechanism)?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240411/684bdc8d/attachment.htm>