[Geoserver-devel] [jira] Created: (GEOS-4370) Restore ThreadPoolExecutor support for multithreaded imageMosaic/imagePyramid granules loading

Restore ThreadPoolExecutor support for multithreaded imageMosaic/imagePyramid granules loading
----------------------------------------------------------------------------------------------

                 Key: GEOS-4370
                 URL: http://jira.codehaus.org/browse/GEOS-4370
             Project: GeoServer
          Issue Type: Bug
    Affects Versions: 2.1-RC1
            Reporter: Daniele Romagnoli
            Assignee: Daniele Romagnoli
             Fix For: 2.1-RC2, 2.2.x

During some tests, I have noticed that my previous work on supporting ImageMosaic/ImagePyramid granules multithreaded loading through a ThreadPoolExecutor (http://jira.codehaus.org/browse/GEOS-4101) 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.

To restore this support, I will put a systemDefault Hint (linking to a default Executor) on the GeoserverInitStartupListener.
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.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira