jaitools
jaitools copied to clipboard
mbedward
ROIGeometry should allow the specification of a tile cache and a tile scheduler to be used for the getAsImage call
Original author: [email protected] (June 15, 2011 12:50:49)
Rationale: on large system working at high parallelism level (busy image servers) using a single scheduler and a single tile cache can be detrimental. ROIShape at the moment uses the JAI default tile scheduler and tile cache, meaning all the VectorBinarize operations tend to starve the same thread pool and synchronize on the same tile cache.
Original issue: http://code.google.com/p/jaitools/issues/detail?id=154
From [email protected] on June 15, 2011 12:50:50 Interesting. I understand the rationale but I'm unclear on how best to deal with it. My first thought was shouldn't it be up to the client to set the tile cache and tile scheduler via JAI.getDefaultInstance() ? But I'm probably missing something.
If new parameters etc are needed, is the ROIGeometry class the best place to implement them ? As far as I can see in the ROIShape sources, it doesn't make any explicit reference to tile cache or scheduler - it just defers to whatever TiledImage is using.
As an aside: when I was fixing DiskMemTiledCache-related bugs recently I was thinking about adding our own TileScheduler class to go along with it.
From [email protected] on June 15, 2011 12:50:51 In large systems you don't have a single system wide tile scheduler and tile cache, you manually set one per request to increase scalability instead. You don't normally see the issue with desktop systems, and neither with the average GeoServer install, again one has to scale up to deep, large JAI chains and hundreds of terabytes of data to see the issue pop up
From [email protected] on June 15, 2011 12:50:52 I understand. And I guess with the code as it stands, you would have to be able to specify the cache and scheduler at the ROIGeometry level to have it used by VectorBinarize.
I'm keen to see this option added, but what worries me is drifting into an API that requires transmission by oral tradition, ie. if you don't know someone who already knows the hidden secrets, you're stuffed (like with gt-coverage). It seems odd to have an ROI class dealing with such settings. I don't think a new user would go looking for them there. So I wonder if there is some more intuitive way of arranging the API ? Perhaps some new class that can be set up to allocate such resources to client objects as required, which the jai-tools operators are aware of ?
From [email protected] on June 15, 2011 12:50:52 Why rely on oral tradition when we can use javadoc? ROIGeometry.setRenderingHints(...) with appropriate javadocs would be good imho?
In the system I'm talking about I have a tile scheduler per http request (so no global context) and the request is so large that we also use a separate thread pool just to load the initial images and setup the JAI chain, which results in different ROIGeometry in the same request needing to use separate tile caches. The thread pool means that not even a thread local setup would work.
So I don't see an easy way to setup a context. If adding a method to ROIGeometry is undesirable I guess we can have our own subclass in GeoTools that overrides the getAsImage() method and uses the same rendering hints provided to the mosaic code.
From [email protected] on June 15, 2011 12:50:53 Ah, forgot to say, why separate tile caches? Because tile cache access is synchronized
From [email protected] on June 15, 2011 12:50:54 OK, I'm happy. With the javadocs for the method, plus an example in the as-yet-non-existent user guide (to replace the wiki) I think it will be readily accessible for users.
Thanks for putting up with my questions :)