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

Reply via email to