Dear List,
I’m trying to use extensively isolated workspace and I’ve found a possible issue which I’m going to share with you before we open a ticket:
Steps:
Use geoserver 2.17.0
create an isolated workspace
add a jndi store
load a layer (I’m using gadm level0)
install VectorTyle extension
enable the vector tyle ‘format’ over that layer
trying to retrieve that or other requests I got errors like:
DEBUG [util.ResponseUtils] - Could not locate a layer or layer group with id LayerInfoImpl-3bba14cf:1711882e14e:-11bb within GeoServer configuration, the GWC configuration seems to be out of synch
2020-04-29 16:37:14,813 ERROR [geowebcache.GeoWebCacheDispatcher] - Request failed
java.lang.IllegalStateException: Could not locate a layer or layer group with id LayerInfoImpl-3bba14cf:1711882e14e:-11bb within GeoServer configuration, the GWC configuration seems to be out of synch
at org.geoserver.gwc.layer.GeoServerTileLayer.lambda$getPublishedInfo$0(GeoServerTileLayer.java:396)
at java.base/java.util.concurrent.atomic.AtomicReference.accumulateAndGet(AtomicReference.java:263)
at org.geoserver.gwc.layer.GeoServerTileLayer.getPublishedInfo(GeoServerTileLayer.java:386)
at org.geoserver.gwc.layer.GeoServerTileLayer.isEnabled(GeoServerTileLayer.java:307)
at org.geowebcache.service.tms.TMSDocumentFactory.getTileMapServiceDoc(TMSDocumentFactory.java:138)
at org.geowebcache.service.tms.TMSService.handleRequest(TMSService.java:251)
at org.geowebcache.service.tms.TMSService$$FastClassBySpringCGLIB$$34b3521.invoke()
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:750)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
at org.geoserver.gwc.config.GWCServiceEnablementInterceptor.invoke(GWCServiceEnablementInterceptor.java:58)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:689)
at org.geowebcache.service.tms.TMSService$$EnhancerBySpringCGLIB$$136fc4fa.handleRequest()
at org.geowebcache.GeoWebCacheDispatcher.handleServiceRequest(GeoWebCacheDispatcher.java:406)
at org.geowebcache.GeoWebCacheDispatcher.handleRequestInternal(GeoWebCacheDispatcher.java:268)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:177)
at org.geoserver.gwc.dispatch.GwcServiceProxy.dispatch(GwcServiceProxy.java:80)
at jdk.internal.reflect.GeneratedMethodAccessor853.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
…
Note that I’ve also deleted that file multiple times recreating it with the UI with no success.
It started working once workspace isolation has been disabled.
Do you have a stack trace or anything else to go on Carlo? I have not used isolated workspaces yet myself, does it work if the workspace is not isolated?
I am sharing some initial thoughts, just to share my understanding:
GWC does not have a built-in concept of namespace, if you look you can see it generates something like prefix_layer_name which works well in many cases
XML namespaces (and prefix) is used to make sure we are specific when talking about what a data means, allowing us to locate the schema used for validation
isolated namespaces are intended to be used when the schema is defined externally, and when there is no “global service” so the content is only available via a workspace specific WFS endpoint
So I think this setup, has been focused on publishing XML content without conflict, and has not deeply considered WCS/WMS (which is possible) or WMTS (which may not even offer a virtual service for unambiguous access). Right now we “run” an emended GWC for publishing tileset, think to support your use case we would need to run one per virtual workspace. So possible but not included in the present design.
I did not work directly on this integration so I would need to dive into the code to confirm the above speculation.
Isolated workspaces were introduced to allow multiple workspaces (end-points) to be associated whit the same name-space, as Jody mentioned, this is particular relevant and useful for WFS.
If an workspace its declared as isolated, then its content can only be acceded in the context of that workspace.
GWC services, like WMTS and TMS, try to look up the cached layers by their ID, but if the workspace they belong too its isolated, that lookup will only succeed if done in the context of the isolated workspace virtual end-point.
Example of global access and an workspace virtual en-point access (in that order):
This where the access of the layer its checked [1] by the isolated workspaces code.
I identified the following issue; Looks like both WMTS and TDMS when building their capabilities document get all the layers by their ID’s and assume that they should be available, if not then its because the GWC configuration got out of sync.
Their code needs to be updated and recognize the situation where certain layers are not available because they belong to an isolated workspace and the GetCapabilities request being answer was issued globally or in a different workspace end-point.
Dear All,
thanks for your reply, so as far as I’ve understood this problem is related to the integration between GWC (embedded) and geoserver.
GWC do not have any knowledge about the workspaces this is why it works only if the workspace is selected using the path and not the layername.
What do you think if we configure the integrated gwc to leverage on the path rather than on the workspace:layername?
If this is acceptable for you, do you think that a patch is possible? I haven’t seen the code so I don’t really know the effort needed, if it’s not so complicated, maybe I can help.
