aaime74 wrote:
...
Hi.
Kind of restarting from the beginning, I think that the first question
to ask is whether whatever method which actually does the rendering of
the maps, and which is "heavy" in terms of resources, is capable of
being interrupted cleanly in the middle. Is it capable itself of
checking regularly if it should continue doing the work ? Or else, if
you "shoot it down" does it mop up after itself, or does it leave stuff
to clean up all over the place ?
From an overall design point of view, it seem to me that you have two
very different types of processes going on : the first type is the
management of the HTTP requests, connections, protocol, etc.., which is
something that should be efficient, light-weight and quick, should
detect (whenever possible) that the client has broken the connection and
so on. That part should also serve the response to the client, when the
full response is ready as a static object on disk e.g.
The second part is the generation of that content, which by it's nature
is slow and heavy, but has a very simple interface ("create this
content"; "stop right now"; ..).
Personally, I would tend to try to separate the two parts, and create a
separate process to handle the content generation, a bit like a database
back-end. It seems to me that it would then be easier to "wrap" this
process in a simple management wrapper which can interrupt the content
generation when receiving some signal from the first part, and cleanup
properly, without tying up resources useful to the HTTP part in the
meantime.
Such a separation may also simplify aspects such as caching of
previously generated content, or load-balancing several content generators.
Maybe you should have a look at Apache MINA for the content-generation
side ? (http://mina.apache.org/)
The "(whenever possible)" above refers to the fact that a number of
things outside of your control can come in the way of such detection :
proxies, firewalls and the like. If the ultimate client breaks the
connection, it is not guaranteed that Tomcat itself would notice this
right away.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
