Ciao Andrea,
did you think about the interactions with the Views in GridCoverage?
This could be a good occasion to get rid of them and/or harmonize with
the CoverageRenderer.

Feedback?

Regards,
Simone Giannecchini
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:      +39 0584 962313
mob:    +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

-------------------------------------------------------



On Sat, Jul 2, 2011 at 11:17 AM, Andrea Aime
<[email protected]> wrote:
> Hi,
> today I was looking at a windows specific build failure on
> GeoServer, http://jira.codehaus.org/browse/GEOS-4657
> The issue was happening while GeoServer was configuring a image mosaic, a
> couple of files would remain open.
> Now, the code already tries to limit the files to be read and cleans up
> after itself by disposing the coverage
> once the needed metadata was extracted, so I could not find out why the two
> files were still kept open.
> The build would then fail under windows because those files were test
> artifacts, the code would then try
> to delete them and fail on windows because they were still open (under Linux
> you can delete a open file,
> but on windows not).
> The files were kept open because the rendered image backing the coverage was
> a mosaic of two
> ImageRead operations, and the image read operation keeps the file open until
> it's disposed to allow
> for deferred loading of tiles out of the file.
> Turned out it's GridCoverage.dispose(...) fault. Or at least, a
> misunderstanding of what it does.
> I supposed that would get rid of the entire chain backing the rendered image
> used in the coverage,
> but it does not.
> This has some sense, while we can assume the last image in the chain is
> "owned" by the coverage,
> the same cannot be said by the sources of that image, they could indeed be
> used in some other place.
> However in most cases one really wants to delete the whole chain and close
> those pesky ImageRead
> operations.
> This can be done by the following code:
>         gc.dispose(true);
>         if(gc.getRenderedImage() instanceof PlanarImage) {
>             ImageUtilities.disposePlanarImageChain((PlanarImage)
> gc.getRenderedImage());
>         }
> Yet that is not really handy... what I would like to propose is to add a
> GridCoverage2D.disposeChain()
> that would nuke the entire chain, no questions asked, and thus releasing all
> resources consumed
> by it.
> Of couse the method would have a warning telling the user that the method
> can be safely used
> only if the image chain backing the coverage is not shared with anything
> else.
> Opinions?
> Cheers
> Andrea
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:      +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to