-
Bug
-
Resolution: Done
-
Major
-
3.6.6.Final, 3.7.2.Final
-
None
XNIO's WatchServiceFileSystemWatcher has a possibility to prune all file change events and miss to invoke FileChangeCallback to notify the change event. Hence, Undertow has a possibility not to detect the file change and updating JSP does not trigger recompilation.
—
When an existing file is updated by using "mv" command from the different filesystem or the different directories having different quota settings,
three events StandardWatchEventKinds.ENTRY_DELETE (REMOVED in XNIO), StandardWatchEventKinds.ENTRY_CREATE (ADDED in XNIO) and StandardWatchEventKinds.ENTRY_MODIFY (MODIFIED in XNIO) happen for the updated file.
mv command tries to invoke "renameat2" system call but it's not possible due to EXDEV (Invalid cross-device link) between the different filesystems or different quotas. So, it internally invokes "unlink" to remove the existing file, invoke "open" a file with the same name with O_CREAT, then invoke "write" and "utimensat". So, this is why all three events are notified for the same file at the same time.
XNIO's WatchServiceFileSystemWatcher prunes the duplicated file change events in https://github.com/xnio/xnio/blob/3.6.6.Final/nio-impl/src/main/java/org/xnio/nio/WatchServiceFileSystemWatcher.java#L122-L142
And, if REMOVED, ADDED and MODIFIED are notified for the same file at the same time, all three file change events are removed from the results by the pruning processing.
- is cloned by
-
JBEAP-17308 [GSS](7.2.z) Undertow/XNIO file watch service has a possibility to prune all file change events and miss to invoke FileChangeCallback
- Closed
- is incorporated by
-
WFCORE-4601 Upgrade XNIO to 3.7.3.Final
- Closed