There is a file handle leak when executing WPS processes with coverage input
in GeoServer 2.7.x. I don't see any changes on master or 2.8.x that would
have fixed this but I was hoping that someone could confirm this.
In order for a file handle leak to occur, the process must have one or more
GridCoverage2D inputs, the process must execute successfully, the input
coverage must not be returned as the output and the process must not be
internally disposing the input coverage(s). ras:RasterAsPointCollection is
one of the default processes that can be used to reproduce the leak.
Steps to reproduce:
1. Start up a GeoServer with the WPS extension installed.
2. Save this image somewhere GeoServer can read it:
3. Create a new GeoTIFF store using the sample image and publish the layer.
4. Open the WPS Request Builder, select the ras:RasterAsPointCollection
process, select the tazdem layer and set the output to application/json.
5. Click the Generate XML button, and copy and save the XML into a file
named leak.xml.
6. Run the following curl command a certain number of times (e.g., 25):
curl -d @leak.xml -v -o out.txt -H "Content-Type: text/xml"
"http://localhost:8080/geoserver/wps"
7. Run "ps -ef | grep java" to get the pid.
8. Run "lsof -p <pid> | grep -c tazdem.tiff" using the pid from the previous
step and you should see that the number of tazdem.tiff file handles will
match the number of times the curl command was run.
I have run into similar problems before, it occurs when a process creates a raster and does not register it.
(A coverage returned as a result is cleaned up, any other resources you make use of during the course of executing your process should be registered with a thread local data structure for subsequent cleanup).
There is a file handle leak when executing WPS processes with coverage input
in GeoServer 2.7.x. I don’t see any changes on master or 2.8.x that would
have fixed this but I was hoping that someone could confirm this.
In order for a file handle leak to occur, the process must have one or more
GridCoverage2D inputs, the process must execute successfully, the input
coverage must not be returned as the output and the process must not be
internally disposing the input coverage(s). ras:RasterAsPointCollection is
one of the default processes that can be used to reproduce the leak.
Steps to reproduce:
Start up a GeoServer with the WPS extension installed.
Save this image somewhere GeoServer can read it:
https://github.com/geoserver/geoserver/blob/master/src/main/src/test/java/org/geoserver/data/test/tazdem.tiff
3. Create a new GeoTIFF store using the sample image and publish the layer.
4. Open the WPS Request Builder, select the ras:RasterAsPointCollection
process, select the tazdem layer and set the output to application/json.
5. Click the Generate XML button, and copy and save the XML into a file
named leak.xml.
6. Run the following curl command a certain number of times (e.g., 25):
curl -d @leak.xml -v -o out.txt -H “Content-Type: text/xml”
“http://localhost:8080/geoserver/wps”
7. Run “ps -ef | grep java” to get the pid.
8. Run “lsof -p | grep -c tazdem.tiff” using the pid from the previous
step and you should see that the number of tazdem.tiff file handles will
match the number of times the curl command was run.