Hi all,
During some tests, I have noticed that my previous work on supporting ImageMosaic/ImagePyramid granules multithreaded loading through a ThreadPoolExecutor is not properly working anymore. This happens in case you restart geoserver and then you try a multithreaded loading on a previously configured layer. (That capability have been provided by means of a CoverageAccess interface which you can use to configure/tune the ThreadPoolExecutor to be used as Hint for the imageMosaic/imagePyramid GridCoverageReaders. During geoserver startup, the CoverageAccessInitializer is invoked to setup the executor.)
After some investigation, I have noticed that right now there is a WMSValidator which validates configured coverages by asking for a GridCoverageReader on each raster layer. However, this step is performed before the geoserver initializers are invoked (JAIInitializer, CoverageAccessInitializer, ResourcePoolInitializer…), therefore there is no configured Executor yet and the GridCoverageReaders are cached in the ResourcePool without the proper Hint.
What I would do to restore this support, is putting a systemDefault Hint (linking to a default Executor) on the GeoserverInitStartupListener which is similar to what is done with FilterFactory, FeatureFactory, StyleFactory,…
By this way, such a Hint will be found when asking for GridCoverageReaders during catalog validation and cached readers will make use of that executor.
Moreover, the code initializing the CoverageAccess will look for the Executor within Hints and then it will adjust the parameters (keepAliveTime, poolSize) by parsing the configuration.
If there are no objections on this, I will open a JIRA, propose my patch and fix this.
Since this is a regression with the previous behavior, is there a way to have some initializers which are executed before any catalog loading?
Best Regards,
Daniele
–
Ing. Daniele Romagnoli
GeoSolutions S.A.S.
Software Engineer
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 328 0559267
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://it.linkedin.com/in/danieleromagnoli
Not that I know much about the domain but it seems like a pretty reasonable solution to me.
On Thu, Feb 10, 2011 at 7:20 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:
Hi all,
During some tests, I have noticed that my previous work on supporting ImageMosaic/ImagePyramid granules multithreaded loading through a ThreadPoolExecutor is not properly working anymore. This happens in case you restart geoserver and then you try a multithreaded loading on a previously configured layer. (That capability have been provided by means of a CoverageAccess interface which you can use to configure/tune the ThreadPoolExecutor to be used as Hint for the imageMosaic/imagePyramid GridCoverageReaders. During geoserver startup, the CoverageAccessInitializer is invoked to setup the executor.)
After some investigation, I have noticed that right now there is a WMSValidator which validates configured coverages by asking for a GridCoverageReader on each raster layer. However, this step is performed before the geoserver initializers are invoked (JAIInitializer, CoverageAccessInitializer, ResourcePoolInitializer…), therefore there is no configured Executor yet and the GridCoverageReaders are cached in the ResourcePool without the proper Hint.
What I would do to restore this support, is putting a systemDefault Hint (linking to a default Executor) on the GeoserverInitStartupListener which is similar to what is done with FilterFactory, FeatureFactory, StyleFactory,…
By this way, such a Hint will be found when asking for GridCoverageReaders during catalog validation and cached readers will make use of that executor.
Moreover, the code initializing the CoverageAccess will look for the Executor within Hints and then it will adjust the parameters (keepAliveTime, poolSize) by parsing the configuration.
If there are no objections on this, I will open a JIRA, propose my patch and fix this.
Since this is a regression with the previous behavior, is there a way to have some initializers which are executed before any catalog loading?
Best Regards,
Daniele
–
Ing. Daniele Romagnoli
GeoSolutions S.A.S.
Software Engineer
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 328 0559267
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://it.linkedin.com/in/danieleromagnoli
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.