On 29/09/2009 09:47, aaime74 wrote:
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).
... because for future requests, the data already exists and the work is
already done. The consequences of a dropped connection are therefore
reduced because you're not doing the work for every single request, and
any work you are doing isn't completely wasted.
Take for example the situation where a user zooms in one direction,
changes their mind & goes back (say to check a point of origin), then
*again* reverses direction to proceed as before.
If you've cached the responses to the first motion then you don't need
to do the work again when the third motion occurs - and the work done
the first time isn't wasted.
Queuing the requests for generating images would allow you to limit how
much work was being done and reduce the chances of an OOM.
It might simply be that you can't achieve what you want without lots of
RAM and more processing power than you currently have.
You may find that you must either queue the generator requests to manage
the load on the server - at the price of making clients wait for data,
or you that you must add more processing power & RAM.
(It sounds like your current setup can't cope with a single users' peak
load.)
Caching stuff mitigates some of the problems you have but it won't solve
the overall problem (which is not that connections are dropped - it's
that the work done is both wasted and too much for the server to handle).
p
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
