Hi all,
A request has recently come up from users to be able to limit the amount of time or resources a particular request can use up. The goal being to prevent a single wms render request from bogging down the server making it unusable to others.
I know Andrea and Gabriel (and I am sure others) have thought about this in the past. I am curious to hear thoughts about this.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
yeah! java.util.concurrent to the rescue...
still ought to take the time to write down my thoughts about this and see if
they make any sense, but definitely something we could rock at!
yet, we're still a bit short of requirements since the possibilities are so
vast in terms of improving scalability, longevity, reliability...
and all of this, as in plain low level performance testing takes time and is
smoke without a well defined goals and proper benchmarking, but we could at
least start an ideas page so thougths are not lost
Gabriel
On Tuesday 16 December 2008 13:56:02 Justin Deoliveira wrote:
Hi all,
A request has recently come up from users to be able to limit the amount
of time or resources a particular request can use up. The goal being to
prevent a single wms render request from bogging down the server making
it unusable to others.I know Andrea and Gabriel (and I am sure others) have thought about this
in the past. I am curious to hear thoughts about this.-Justin
Justin Deoliveira ha scritto:
Hi all,
A request has recently come up from users to be able to limit the amount of time or resources a particular request can use up. The goal being to prevent a single wms render request from bogging down the server making it unusable to others.
I know Andrea and Gabriel (and I am sure others) have thought about this in the past. I am curious to hear thoughts about this.
Hum... the first element of such requirement is to make
the request interruptible when the timeout is reached.
Even starting a separate thread to serve a WMS request,
I don't know if we can just kill it. Afaik this is very
much discouraged, the thread should be expecting an
interruption request and orderly stop working, releasing
all resources it requested, meaning it should work in
a granular way and periodically check for a stop request.
Rendering wise we have such a check, that works fine
for vector data, as the stop rendering flag is checked
between each two features, but there are cases where
that does not help:
- rendering a coverage (how do we stop such thing
once we asked java2d to render the RenderedImage
we prepared? I don't know).
- executing a query, loading data (networks timeouts
in sql queries, in remote wfs connections and the like).
If it was only for the vector data, we would not need
to play with concurrent api, we could just setup a
timer that tells the renderer to stop when the
timeout is reached, and notice the timeout was reached
and throw back a service exception instead of an image.
It's the rest that worries me more, as it seems
we need better collaboration out of the datastores
and out of the grid coverage renderer to get there.
The datastore thing is more of a corner case so I guess
the main blocker there is the grid coverage renderer.
Simone, any quick solution for that?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.