RFR: 8297275: WatchService delay with PollingWatchService causes test failures

[Alan Bateman]

On Wed, 23 Nov 2022 19:11:06 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> A reasonable explanation, but I disagree with the conclusion. The implementation of getLastModifiedTime comes from UnixFileSystem code which is similar between the Unixes [2]. To your question, AIX uses nanosecond information to compute the mtime as well. In addition, PollingWatchService explicitly converts the modification time to milliseconds [1].

Would it be possible to run this on the AIX system and paste in the output? The output is just the last modified time, it wouldn't reveal anything about the system.

            Path file = Files.createTempFile("foo", "bin");
            try {
                FileTime t0 = Files.getLastModifiedTime(file);
                try (var ch = Files.newByteChannel(file, StandardOpenOption.APPEND)) {
                    ch.write(ByteBuffer.allocate(1000));
                }
                FileTime t1 = Files.getLastModifiedTime(file);
                System.out.format("%s%n%s%n", t0, t1);
            } finally {
                Files.delete(file);
            }

I think this is close to the test that is failing for you. The main thing I'd like to see is whether the time of last modification is changed or not.
 
> Does this mean that you'd prefer the polling rate match always match the initial delay? I can see an argument for this. But in that case, I would advocate for the addition of a delay like the one proposed by this PR. Once the call to register a path returns, I think it's reasonable to assume that any change to the registered Watchable would be noticed by the WatchService.

Registering a directory to watch will first scan the directory to get the names and time of last modification for all entries. This is done by the register method before before it adds the directory to the map that is scanned by the poller thread. Hopefully this makes it clearer why POLLING_INIT_DELAY doesn't really make sense. It means first the poller thread will do its first poll of all directories from 1s of first registration, then at 2s interacts thereafter.

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

PR: https://git.openjdk.org/jdk/pull/10824