Le mardi 05 avril 2016 08:39:29, Andrea Aime a écrit : > On Mon, Apr 4, 2016 at 8:01 PM, Even Rouault <even.roua...@spatialys.com> > > wrote: > > 2.0 can be used, but the key is to use the same swig version (at least > > major > > number) to generate the .jar and the native .cpp files. > > Hi Even, > thanks for pitching in, we can really use your opinion. > > Unlike CGI based servers we have a higher bar for production use, as > a single segfault will take down the entire server (even with watchdogs > restarting > it, that will mean minutes with no service at all). > Under our normal operation conditions the process will stay up for > days/weeks/months, meaning we're also quite sensible to any form of memory > leak, and of > course it means for all that time GDAL will be under multithreaded load for > all that time. > > So far recent releases of GDAL 1.x have worked well, but if I understand > correctly, > GDAL 2.0 has been a significant refactor.
More on the OGR side. Some overview at https://svn.osgeo.org/gdal/branches/2.0/gdal/MIGRATION_GUIDE.TXT > Do you know of any other project > that > has already used GDAL 2.x in anger under conditions similar to GeoServer > ones? Not really, but as often with OS projects, people only communicate when things don't work ;-) That said, multithreaded use of GDAL is OK when reading from raster datasets (with some care when dealing with VRT : see "Multi-threading issues" at end of http://gdal.org/gdal_vrttut.html). But they are currently design limitations in the global raster block cache that make multithreaded raster writing unsafe (true for any GDAL version in 1.X or 2.X series) Even -- Spatialys - Geospatial professional services http://www.spatialys.com ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel