HTTP connections are not returned to the pool in GWC and it blocks subsequent requests.. #1308
Comments
|
When you say "internal", are you talking about the GWC running inside GeoServer? What you're pointing to seems to be the HTTP client used by the WMS Layers in a stand-alone GWC instead. Please make sure it's the last time you post a screenshot of code in a report, link to the actual code in the repository instead. |
|
GWC runs inside GeoServer (embedded) but works in usual way with just normal HTTP request. So, the scenario is fully applicable also to standalone GWC. As written above, in case of ServiceException there is no reading attempt from input stream of response and normally working connection releasing code is omitted. Both 2 connections (that by default are allowed per route in HttpComponents) are leased and never returned to the pool, then all other subsequent requests are endlessly waiting... Also if you check who calls GWC.dispatchOwsRequest - it seems only getFeatureInfo type of request. So, no "fake HTTP requests" for normal getMap of WMS from GWC to WMS.. I am not reporting to the wrong repo. Problem is debugged, dirty fix is applied myself (a simple one), but I would like , may be maintainers analyze the case and prefer to fix it by doing a bigger refactoring.. |
|
How in the world have you configured the GWC? It seems like you have setup a WMSLayer manually in gwc.xml rather than simply enabling tile caching in the GeoServer layer configuration, hence the usage of WMSLayer. A normal setup (tile caching tab in the GeoServer layer page) for embedded GWC would have make it use a GeoServerTileLayer instead. Here is what the stack trace looks like in that case: Using a HTTP connection for GeoServer to talk to itself was the first thing the developers integrating GWC with Geoserver tried to avoid, some 15-ish years ago. |
|
Answer: Using geowebcache.xml manual configuration within GeoServer. But it is not related to the problem in general, because there is a standalone mode and behavior will be the same: deadlocking of all subsequent connections to GWC waiting a connection from pool where previous requests (failed with 401 from GeoServer) did not release connections.. |
|
Standalone GWC is a production option, let's say (for me) in dev.env environment it's easier to test everything using GWC embedded. So , it allows creation of geowebcache.xml manually with all necessary tweaks in dev.env with GWC embedded (running as GeoServer from Eclipse in debug) and then use it for prod where GWC is standalone. |
|
#1194 is about the same problem. Reported in 2023. It's critical defect with an easy fix in WMSHttpHelper ... (just dirty fix with the following general code improvement if necessary): |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
GeoServer closes WMS service API with HTTP Basic authentication.
GWC sends internal request to WMS without credentials (if they are not configured) and also is not able to authenticate against WMS service..
WMSHttpHelper.connectAndCheckHeaders throws Service Exception (because WMS service responds with 401):
So, in this workflow an allocated (from the pool) HTTP connection is never released back to the pool.
By default 2 connections are per HTTP route (is is also questionable, shouldn't we allow more for internal GWC-WMS communication?)
So, connections are taken from the pool and never returned. All subsequent connections will wait pool without timeout.. (timeone is alos needed for internal connections).
AN easy fix is to put all content of connectAndCheckHeaders into try{}finally{}:
Something like this (tried quickly and locking problem is gone at least, regardless workflow connection is returned to the pool):
The text was updated successfully, but these errors were encountered: