Gabriel, Thanks for the thoughtful reply. As I understand, we have two possibilities: 1: An external user is trying to hit this layer with the wrong agent, and the resulting hiccup is being logged as a server error instead of just being noted in the logs. 2: There really is something wrong with the layer in question (HCVAE)
When I set the GeoServer logs to verbose and hit this url: http://atlas.track.gov.au:8080/geoserver/gwc/demo/HCVAE?gridSet=EPSG:4326&format=image/png We get a stack of fallback "cannot convert url" errors: >>>> 2012-04-16 09:04:39,648 DEBUG [geoserver.logging] - FINISHED CONFIGURING GEOSERVER LOGGING ------------------------- 2012-04-16 09:04:39,649 DEBUG [geoserver.config] - Persisted $Proxy138 to /usr/local/tomcat/geoserver_data/logging.xml 2012-04-16 09:04:39,959 DEBUG [geoserver.filters] - filtering http://74.50.62.108:8080/geoserver/web/ 2012-04-16 09:04:39,960 DEBUG [ows.OWSHandlerMapping] - Looking up handler for [/web/] 2012-04-16 09:04:39,960 DEBUG [ows.OWSHandlerMapping] - Looking up handler for [/web/] 2012-04-16 09:04:39,973 DEBUG [geoserver.web] - cannot convert url: jar:file:/usr/local/tomcat/webapps/geoserver/WEB-INF/lib/web-core-2.1.2.jar!/org/geoserver/web/css/blueprint/screen.css to file (URI is not hierarchical), falling back to the inputstream for polling <<<< And eventually a png is rendered. Basically the same result occurs when we hit this url: http://atlas.track.gov.au:8080/geoserver/gwc/demo/HCVAE?gridSet=EPSG:900913&format=image/png So I'm not sure what else to do in order to troubleshoot the actual layer: it is possible someone has set a parameter wrongly, but that doesn't seem to show in the logs. Thanks again for your insight...any further observations would be most appreciated. Kind regards, JB On 16/04/2012 11:00 AM, Gabriel Roldan wrote: > On Sun, Apr 15, 2012 at 9:53 PM, Gabriel Roldan<[email protected]> wrote: >> apparently we lost the ability of logging the full wms request with >> the stack trace. I'll file a bug report about that. >> But in any case it looks more like the client is misconfigured or >> trying to use the WMS-C end point as a pure WMS. >> Check out the list of advertised resolutions for the two gridsets, the >> requested one (0.11861801147460932) is way too far from any of them: >> <view-source:http://atlas.track.gov.au:8080/geoserver/gwc/demo/HCVAE?gridSet=EPSG:4326&format=image/png> >> <view-source:http://atlas.track.gov.au:8080/geoserver/gwc/demo/HCVAE?gridSet=EPSG:900913&format=imag >> ise/png> >> >> I'd say that except if you're actually experiencing this with a valid >> request, as your service is public, it looks more like someone is >> playing with it with a wms client instead of a wms-c one? >> > That is, if it turns out it's not a problem in the server, but just a > client making bad requests, the log message shouldn't be logged as > ERROR, but perhaps just at the debug or info level. Bad user input is > not a server problem, and the error response an expected output. > Unfortunately both the geoserver and geowebcache code bases are > infested of this mistake, presumably just because the developer > thought it was easy to catch his attention during testing. > > So try to check whether some application if yours or your users is > failing when hitting the server with valid input, and if it's not (as > it seems to be the case), just ignore the log message. > > regards, > Gabriel > -- John Brisbin Managing Director, BoaB interactive Pty Ltd POB 802 Townsville, QLD 4810 M: 0407 471 565 | P: 07 3103 0574 Skype: boabjohn | Twitter: @boabjohn ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
