Hey,
not stuck, just waiting for free time to spend on it.
Got a PR btw: https://github.com/geoserver/geoserver/pull/3860
Note this addresses the issue itself, does not:
- implement the switch to using WatchService, since that can be more
involved and require proper testing under different scenar
So how is this one progressing? Seems stuck
Cheers
Andrea
On Sat, Oct 19, 2019 at 11:04 AM Andrea Aime
wrote:
> On Sat, Oct 19, 2019 at 2:37 AM Jody Garnett
> wrote:
>
>> Thinking further ... listening to "gwc-layers/*" is a poor idea and
>> unnecessary.
>>
>> Since we completely know the nam
On Sat, Oct 19, 2019 at 2:37 AM Jody Garnett wrote:
> Thinking further ... listening to "gwc-layers/*" is a poor idea and
> unnecessary.
>
> Since we completely know the names of these files (from their matching
> layer objects). There should be no need to scan the directory for changes
> ... we
Thinking further ... listening to "gwc-layers/*" is a poor idea and
unnecessary.
Since we completely know the names of these files (from their matching
layer objects). There should be no need to scan the directory for changes
... we have enough information to do this file by file which should be m
On Fri, 18 Oct 2019 at 10:17, Jody Garnett wrote:
> That is ... unexpected.
>
> So there are other solutions to notify tile cache state across the cluster
> right. Are they more appropriate then depending on file system polling
> here?
>
I would suspect so. The catalog does so it should be poss
That is ... unexpected.
So there are other solutions to notify tile cache state across the cluster
right. Are they more appropriate then depending on file system polling
here?
On Thu, Oct 17, 2019 at 11:27 PM Gabriel Roldan
wrote:
>
>
> On Thu, 17 Oct 2019 at 13:46, Jody Garnett wrote:
>
>> B
On Thu, 17 Oct 2019 at 13:46, Jody Garnett wrote:
> 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
> 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 f
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
