aaime74 schrieb:
Well, something like that has actually been done already, it's called tile caching, and works under the restrictive conditions that you can force the client to make requests in predetermined sizes and tiles. As for applying this to the general case, I invite you to have a look at how big the "raster surface" is and how much space is required to actually store on the disk a full map (only _one_ map, some GeoServer installs do serve 500-1000 different layers) here:
I'm not saying you should store the whole map all at once. My approach was to dynamically cache requests that the client may want to make in advance. An easy example would be if a client makes a request for the city center, you create the map for the city center plus the suburbs around it and store it somewhere, then return the city center. If the user then moves around a bit to see the suburbs, you already have the whole map cached and just need to return it, no need to do any further calculation.
If you then also compress the image on the fly while you are reading it from disk (or from some memory cache), you will start writing to the output stream very soon (also detecting the dropped connection very soon) and the servlet will not need much RAM. Of course this does not work if you just use Java's built-in PNG encoder.
Obviously, caching always comes with the price that you will have the occassional cache miss :-) That is, this does not work for every request but may decrease load and RAM usage a lot for typical use cases.
In your OP you write: "Unfortunately in the meantime the older requests are still running, drawing a map takes time and a lot of memory, for example the above request, which is a small one btw, allocates a BufferedImage of 700KB." This indicates that you (1) seem to not use any caching ("drawing a map takes time" - with caching the map would already have been drawn) and (2) you use BufferedImage which of course does not allow you to PNG-encode on the fly. Both problems would be solved with the above suggestion.
Markus --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
