ResourceWatcher: Use native JDK7 APIs

[spinscale]

The ResourceWatcherService supports watching files based on three different intervals. Since we require java 7 for Elasticsearch, we can use the WatchService for files, which - depending on the file system (osx and windows do not support this IIRC) - then is notified of immediate updates of files and does not require polling, but still falls back to polling in case this notification functionality is not available.

The JDK contains a SensitivityWatchEventModifier class, which could be used as default and we should be able to make this configurable as well, so we can still configure the different intervals.

[jpountz]

+1

[elasticmachine]

Pinging @elastic/es-core-infra

[fabiodrg]

What is the current state for this issue? Should we start slowly using the WatchService? I would like to help, but there are many places where ResourceWatcherService is used, where to start.

[danielmitterdorfer]

@fabiodrg666 thanks for your interest and your offer to help. The intention behind this change is that we keep ResourceWatcherService but only change its implementation so that it uses the JDK's WatchService internally, i.e. usages of the class ResourceWatcherService should not be replaced. If you want to work on this change, our contribution guidelines as well as our testing documentation should help you to get started.

[jaymode]

I've looked into this previously and one issue that prevented me from opening a PR is that the macOS implementation is based entirely on polling and does not have a native file change notification implementation in the JDK. I do not believe that this will be feasible to use unless we contribute a native macOS implementation to the JDK. JDK Issue: https://bugs.openjdk.java.net/browse/JDK-7133447

[rjernst]

While this was an interesting idea, I remember that the jdk watcher also was not quite a direct replacement for the resource watcher in Elasticsearch. Given that, combined with the complications mentioned by @jaymode, I think after 5 years it is unlikely we will ever get around to trying this, and there is no clear incentive. Thus, I think we can close. WDYT @jaymode ?

[jaymode]

I agree with closing. Let’s revisit if/when the JDK has a proper native implementation for our supported operating systems