Markus Meyer wrote:
>
> Jason Brittain schrieb:
>> The first time you call flush, it will send the HTTP response
>> headers to the client, so you would need to first set the headers before
>> flushing. That sounds difficult for you to do because you're writing an
>> image, and one of the headers would be Content-Length, which you probably
>> don't know until your image is generated.
>
> Actually, Content-Length is optional as per the HTTP-1.1 spec:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
>
> However, my take on the OP is that a better optimization strategy in
> this case would be to just cache a larger image on the server rather
> than generating every image on-demand. That is, when the user is moving
> around in the image, the server, on the first request, would calculate
> the image for a much larger portion of the map than requested and stores
> it on disk in temporary storage (or in some cache area in RAM, if
> feasible, after all RAM is cheap these days and 64-bit machines can have
> lots of RAM). Storage of the images would not be done all at once but in
> tiles. When then user then moves around in the client, the requests just
> reads the tiles of the created image from disk, puts them together and
> clips the borders, then compresses the image and sends it to the client.
> It is possible that PNG even has some support for compressing parts of
> an image so the tiles itself could be already stored in compressed
> format, but it's been a while since I read the PNG spec last time. The
> same could be done for zooming by storing images in a pyramidal
> structure, like it is done in pattern recognition. While the user is
> moving, a background thread associated with the client could try to
> anticipate where the user is likely to be moving to and calculate the
> given tiles in advance. Actually, this sounds like an interesting
> project for several Ph.D. theses...
>
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:
http://geowebcache.org/trac/wiki/resources
(the site is describing the tile cache companion to GeoServer, called
GeoWebCache)
So, it is somewhat doable, but only for a few backgrond layers that
do not change that often (once a month may be ok if you don't need
to zoom in too much).
Cheers
Andrea
--
View this message in context:
http://www.nabble.com/How-to-check-if-the-client-dropped-the-connection-tp25641481p25651562.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
