Hi there, Got a situation here: data directory with 100 workspaces and over 80K layers. Gotta be used in a clustering setup with the JMS clustering extension.
Good news is 2.16.0, with the latest startup fixes, starts up in 40 seconds as opposed to 8-9 minutes for 2.15.0. Haven't tried 2.15.3 but the fixes are probably there too. 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. 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. 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. PS: if you're gonna mention jdbccatalog don't even bother. Having a better catalog backend is a totally (and worthy) different topic. Cheers, -- Gabriel Roldán
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
