HTTPURIHandler has defaults Connection and Read timeouts of 10 s specified as constants, but does not apply them. The actual defaults are 0, which is interpreted as infinity. This can leave the HTTP request hanging indefinitely inside a global lock on Schemas.
CodeHaus Comment From: bencaradocdavies - Time: Sat, 14 Mar 2015 14:37:42 -0500
these low timeouts (infinite reduced to 10 seconds) cause gt-xml SchemaCacheOnlineTest to fail almost every time. This suggests a possible severe impact on app-schema. Note that it is not unusual to have much longer timeouts from remote schema sources including schemas.opengis.net.
Workaround is to append this to the surefire argLine in the top-level pom:
These options may now be required in production by GeoServer 2.7.0 app-schema deployments.
CodeHaus Comment From: bencaradocdavies - Time: Sat, 14 Mar 2015 14:38:39 -0500
To see the failures, create the empty file ~/.geotools/schema-resolver.properties and build with -Ponline.
CodeHaus Comment From: bencaradocdavies - Time: Sat, 14 Mar 2015 15:09:20 -0500
Also, the property names in the javadoc are wrong.
CodeHaus Comment From: bencaradocdavies - Time: Sat, 14 Mar 2015 23:00:13 -0500
Further testing indicates that the failures I am seeing are entirely unrelated to Kevin's changes, and are of no concern for app-schema in production. The association and effectiveness of my "fix" were mere coincidence. Sorry Kevin!
SchemaCache has its own internal timeout setting (60 seconds) and is not influenced by the system properties named above. More detailed investigation and manual testing indicates that the test servers are behaving quite badly today, sometimes timing out, sometimes returning an empty response, and sometimes resetting the connection:
HTTPURIHandler still has incorrect property names in its javadoc. But other than that, please ignore my complaints on this issue.
Mass transitioning all resolved issues that have not been updated in the last month to closed state