> Bad news is FileSystemWatcher is killing the machine. For each instance it > gets one thread eating 100% of one CPU all the time. Reported this before, > just sharing my pain. > > Been looking at replacing the internals of FileSystemWatcher to use > java.nio.file.WatchService, and although at a first glance it looks pretty > straightforward, it's not gonna be that simple. >
Darn, that was the point of making the interface (since we could not use WatchService on Java 7 yet). > There are a number of situations where it just won't work, basically when > the data dir is on any sort of mapped filesystem (NFS, SAMBA, Docker bind > mounts), for which the Linux implementation doesn't work as it relies on > inotify. > > The MacOS implementation is a polling one, but it's gonna be better than > the current custom one anyways. And for Windows, I don't know yet. > Still this was only supposed to be used for a few files like the security settings which require active notification? If a watcher is being setup beyond that ... is it a mistake? In any case it's clear that anyone that has a large catalog will most > probably have it on a shared filesystem to be used by several instances. > So this might require a GSIP, which I'm willing to start, in order to > tackle on the different scenarios, as it can get even more involved as > above described. > Before you go that far can we talk about how FileSystemWatcher is being used... -- Jody
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
