GeoServer cloud is being used with a data directory with dangling references, e.g., layer groups pointing to layers that do not exist any longer (an erroneous situation that base GeoServer is tolerant to). In particular, the test is using a file based data directory.
Now, GetMap requests in this situation cat take seconds longer than on a base GeoServer, following this pattern
- The GetMap request is workspace qualified, e.g., "geoserver//wms?...." and has several layers, and several styles, with style names being simple names, and referring to styles in the workspace, e.g.
styles=myStyle and the style exists in GeoServer as ws:myStyle. In other words, the style exists where it shoud be.
- The WMSWorkspaceQualifier callback tries to qualify the style turning it into "ws:myStyle" and passing it down to the catalog to verify it's there
- On the way to the facade, the LocalWorkspaceCatalog intercepts the request and turns in into catalog.getStyleByName(WorkspaceInfo, "ws:myStyle"), hence basically doubly-qualifying the reference
- Inside the Eventually consistent catalog facade, the lookup is performed and it returns nothing. The code checks if the catalog facade is consistent, and finds there are pending operations, causing the code to perform a few retries, after 10, 25 and 50 ms (total, 85ms). In the end, the qualified lookup fails and the un-qualified remains (and this works because LocalWorkspaceCatalog will eventually qualify it later)
- With 10-ish styles, this results in a 850ms delay on responses
Now, why is the facade thinking it's not consistent? Because it's full of pending operations that cannot be run, due to the layer groups pointing at non-existing layers. This cannot be resolved.
I found that the data dir loader populates a facade successfully, and it's in the synch operation that all the pending operations are generated.
Thinking out loud, when reading a data directory from disk, shouldn't pending references be pruned before the synch? In this particular case, the layer references will just never be there.
GeoServer cloud is being used with a data directory with dangling references, e.g., layer groups pointing to layers that do not exist any longer (an erroneous situation that base GeoServer is tolerant to). In particular, the test is using a file based data directory.
Now, GetMap requests in this situation cat take seconds longer than on a base GeoServer, following this pattern
styles=myStyleand the style exists in GeoServer asws:myStyle. In other words, the style exists where it shoud be.Now, why is the facade thinking it's not consistent? Because it's full of pending operations that cannot be run, due to the layer groups pointing at non-existing layers. This cannot be resolved.
I found that the data dir loader populates a facade successfully, and it's in the synch operation that all the pending operations are generated.
Thinking out loud, when reading a data directory from disk, shouldn't pending references be pruned before the synch? In this particular case, the layer references will just never be there.