Markus Meyer wrote:
>
> 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.
>
Sorry, I've lost you there. How is drawing a bigger image going to solve
the problem, which in the end is both a CPU waste but also an OOM
due to too many images being generated at the same time because
of the user zooming in and out fast (most of them are actually not
wanted anymore by the client which in the meantime will drop the
connection).
If anything your suggestion seems to make the client wait longer and
the server OOM faster.
Markus Meyer wrote:
>
> 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.
>
WMS and tile systems are related, but they don't work the same way,
I cited tiling because it's the thing people know the most given the
Google maps popularity.
A desktop WMS client won't use any pre-defined tile structure, each
request will be different in terms of layer requested, zoom level,
and area. The potential for caching is very, very low.
The tile system are on the other side setup to make caching possible
and efficient by imposing structure on the requests, but what I'm dealing
with here is pure WMS.
What I'm talking about here are the industry standard solutions for
WMS map rendering. We can discuss this at lenght and we could come
out with some interesting new way that was not tried before in the
field. But in the meatime I would really appreciate if anybody could
answer my first question: how does one detect the client connection
has been dropped? Is there any way? Does anybody know?
Markus Meyer wrote:
>
> 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.
>
The rendering subsystem actually takes a Graphics2D. If you can suggest
ways to draw lines, points and polygons on a raster image that is not
memory bound (like a buffered image) and has no "sewing" effects
(like tiles, that do break labelling, long story, don't get me started on
this)
I'm all ears.
Cheers
Andrea
--
View this message in context:
http://www.nabble.com/How-to-check-if-the-client-dropped-the-connection-tp25641481p25659184.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
