[GIS] QGIS WFS Error – Could not commit changes to layer

geoserverqgiswfs-t

I have a PostGIS database being served by Geoserver. I can load the layers I want into QGIS no worries; however whenever I try to edit the layer I get this error message:

Could not commit changes to layer X
Errors: ERROR: 1 geometries not changed.

Provider errors:
empty response

Does QGIS-2.4 actually support wfs-t capabilities at the moment?

EDIT

QGIS

Network request http://*******.com:**/geoserver/****/wfs?SERVICE=WFS&VERSION=1.0.0&SRSNAME=EPSG:3308 timed out

Geoserver

2014-09-29 09:43:06,297 INFO [geoserver.wfs] - 
Request: getServiceInfo
2014-09-29 09:43:06,330 INFO [geoserver.wfs] - 
Request: getServiceInfo
2014-09-29 09:43:06,330 INFO [geoserver.wfs] - 
Request: describeFeatureType
    service = WFS
    version = 1.0.0
    baseUrl = http://***.com:**/geoserver/
    typeName[0] = {*****}*****
    outputFormat = XMLSCHEMA

POST Request

<Transaction xmlns="http://www.opengis.net/wfs"     
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0.0"   
xmlns:NCTPROP="NCTPROP" service="WFS" xsi:schemaLocation="NCTPROP  
http://****.com:****/geoserver/****/wfs?   
SERVICE=WFS&amp;VERSION=1.0.0&amp;REQUEST=DescribeFeatureType&amp;TYPENAME=*****
v&amp;SRSNAME=EPSG:3308&amp;username=****&amp;password=****" 
xmlns:gml="http://www.opengis.net/gml"><Insert xmlns="http://www.opengis.net/wfs">
<nct_cov xmlns="****"><prop_name xmlns="****">test</*****><status 
xmlns="****">lol</*****><geom xmlns="****"><gml:MultiPolygon 
srsName="EPSG:3308"><gml:polygonMember><gml:Polygon><gml:outerBoundaryIs>
<gml:LinearRing><gml:coordinates cs="," ts=" ">COORDS HERE</gml:coordinates>
</gml:LinearRing></gml:outerBoundaryIs></gml:Polygon></gml:polygonMember>
</gml:MultiPolygon></geom></*****></Insert></Transaction>

Best Answer

This looks like a bug in GeoServer.

GeoServer needs to identify when a schemaLocation references the GeoServer's own WFS service and does this by looking at the hostname of the URL and comparing it to a list of known hostnames it generates at start up by looking at the network interfaces.

If it fails to recognize itself it will make an HTTP request to retrieve the schema which will lead to a deadlock between the threads handling the two requests. This deadlock will also block all attempts to resolve schemas including all requests that include any schemaLocation attribute at all.

Windows is particularly susceptible because it doesn't recognize localhost or hostname.local but will resolve them to itself. This can affect other OSes though as a result of proxies, address translation, or DNS aliases not reachable by a reverse lookup or which are added after GeoServer starts up.

Adding the missing hostnames to the hosts file may help.

Related Question