Why do I need to restart tomcat when using WFS from GeoServer across different apps and workspaces?

Question

I've built a couple of apps that consume WFS 1.1.0 from GeoServer 2.2.2. I organise my layers in different workspaces, and they have a range of sources including shapefile, oracle, postgres etc.

I've noticed that wfs services only work in one application at a time. If i bounce tomcat then whichever app I go to first will be able to consume wfs. If i hit a second app, no luck. I can see the request for the second app being made in the logs:

14 May 16:06:24 INFO [geoserver.wfs] -
Request: getFeature
service = WFS
version = 1.1.0
baseUrl = http://localhost:8080/geoserver/
query[0]:
    srsName = EPSG:3857
    typeName[0] = {http://www.openplans.org/usaid}jamoats_geom
outputFormat = text/xml; subtype=gml/3.1.1
resultType = results

Puzzled. Am i missing some config or security setting?

Thanks!

<---Update after iant's request for more info-->

I inherited this stack from another developer... I'm running nginx/0.7.65 & Tomcat 6 on Ubuntu 10.04.4 LTS. geoserver.war is deployed at /var/lib/tomcat6/webapps. I build a simple web-app (js/css/html) and package as a .war. I psftp this over to my server next to geoserver. I add sites to nginx for each web-app by editing /etc/nginx/sites-available/default.

I interrogated the XHR responses for a successful and an unsuccessful WFS request. I'm using two projects here to debug; 1.climvar and 2.usaid. If I load up climvar after restarting Tomcat my wfs features display. If I load up climvar after restarting Tomcat, BUT visit usaid first, no wfs features display. I looked at the responses in more detail. In both responses 82 features came back:

In the successful response:

xmlns:climvar=”http://www.fasga.com/climvar"...

In the unsuccessful response:

xmlns:usaid=”http://www.fasga.com/usaid”. 

So it seems the wrong namespace is being 'remembered' across my WFS. There is no difference between the request payloads. In the unsuccessful response, all the prefixes are null. Instead of:

<climvar:id>0</climvar:id> 

I get:

<null:id>0</null:id>

Here's my js layer definition for climvar:

    var layerOpg = new OpenLayers.Layer.Vector(nsClimVar.Constants.OPG_LAYER_NAME, {
        //id : "layerOpg",
        styleMap : nsClimVar.Styles.StyleMaps.styleMapOpg,
        strategies : [new OpenLayers.Strategy.Fixed()],
        protocol : new OpenLayers.Protocol.WFS({
            version : "1.1.0",
            url : "http://" + nsClimVar.Constants.SERVER_IP + "/geoserver/climvar/wfs", // geoserver wfs endpoint
            featurePrefix : "climvar", // geoserver worspace name
            featureType : "opg_new", // geoserver Layer Name
            featureNS : "http://www.fasga.com/climvar",
            srsName : "EPSG:900913" // default
        })
    });

Layers in usaid are declared in the same way. In GeoServer, both workspaces have the namespaces set correctly, both are enabled, both have WFS enabled. I've tried removing the featureNS and featurePrefix params but this makes no difference.

The only workaround I can think of is having all my layers in one workspace which I don't want to do.

Any ideas?

Answer 1

I had similar problems a while ago. In my case it were cache problems. Try deleting the tomcat cache (/catalina/work) and the browser cache. You could also try and let geoserver handle the workspaces.

url : "http://" + nsClimVar.Constants.SERVER_IP + "/geoserver/wfs", 

Answer 2

I suspect an out of memory error: the first application to be accessed will issue a large (how many features are fetched with every layer?) WFS request which completes, but prevents further requests from being carried out successfully.

This explains the works-after-restart behaviour as with a restart all JVM memory would be released and then reallocated again.

To check if this is your case please report the JVM startup parameters used by tomcat:

/bin/ps auxwww | /bin/grep java

is usually enough to find out which parameters have been set.

For a reference consider that you should find values like those suggested in the Geoserver guide in the 'JVM Tuning' para of the 'Running in production' section. In case you don't then you are probably hitting a memory wall.

Apply the values suggested in the guide (your server should have at least 3GB of RAM for those values. In the case of x64 architecture double all of them, including the memory requirement that I just mentioned) and then let us know how it goes.

While not strictly necessary to sort this issue out, please report the vendor and jdk version which can be obtained with the following command:

java -version