Interesting topic... To be honest I don't really think "ability to attend 40 concurrent requests with just 64M heap" should be a requirement for GeoServer, yet, the problem scales up and upping the heap a bit just mitigates it. The actual problem, from a robustness/reliability pov, of giving up on no longer needed requests is an amazing challenge though. I agree with Justin this fits nicely for the longer term plans, and by thinking of it, I beleave there _might_ be a way to do so in a more standard/supported way Servlet API wise. Let me rant about it: If we already had some sort of concurrent job queue, the jobs would be running on a separate thread than the calling one. Jobs would obviously have some kind of identifier, and the calling thread would be waiting for the worker thread to be ready to deliver. So, say the worker thread is taking "too long" to respond. Actually, let's say we want to periodically check on the incoming connection status (every X secs?) and decide whether to ask the Job to abort. Since the calling thread is detached from the working thread, when we check for opening connection status we could ask the client to HTTP redirect to a different URL. This URL would contain the identifier of the running Job. So if the redirect call succeeds the client will issue another connection to the new URL and be attached to wait for the Job to finish. But if the redirect call fails (at the server) the HttpServletResponse.sendRedirect(String url) call will throw an IOException and we can safely ask the working Job to abort. Of course we'd need to first check the client would accept redirects, but since most of them will be web browsers they should.
What do you think? too crazy? I know this idea would not be easily implementable in the _short_ term, but might be worth having it in mind for the Job design. my 2c/ Gabriel Andrea Aime wrote: > Andrea Aime ha scritto: >> Andrea Aime ha scritto: >> ... >> >>> I looked into the servlet API but could find no "supported" way to >>> actually guess if the client connection is still alive >>> or not, it seems one has actually to try and write something >>> on the output. >>> I asked on the Sun J2EE servlet forum and got a couple of answers: >>> http://forums.sun.com/thread.jspa?threadID=5408542 >>> >>> The idea of trying to flush() periodically seems to be a good >>> one, I've read in other places that flushing the output >>> stream should not turn the response into committed status: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4362880 >>> >>> The reason it's important that flush() does not commit >>> the response is that by the time one commits the response >>> the headers have to be set and cannot be modified, >>> and our dispatch system sets them only after the response >>> object has been created (the fully rendered image in our case). >>> Since we want to try periodic flush() call during the rendering >>> we would be in troubles, as the headers are set only after that. >> Hmmm... just looked into the source code of Jetty and Tomcat, >> no go: >> - Jetty ServletOutputStream subclass flush() won't do anything unless >> there is anything written in the output, and if there is, the >> stuff is sent do the client >> - Tomcat will send the headers to the client as soon as you call it. > > Maybe the problem should be attacked the other way, on the input size. > When calling read methods on the input stream they should return -1 > if the stream is ended. But what if the connection has been dropped? > _maybe_ they will throw an exception instead. > Worth a try I guess > > Cheers > Andrea > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
