I agree it's an interesting topic, not sure what scenarios we're focusing on though. Guessing:
I think Andrea is talking about the case where someone zooms in using an OpenLayers client (tiled or not), racking up a request queue of maybe 5-6 maps before getting to the one of interest. I like the dynamic aspect of Gabriels proposal, which I think is for responses that take more than a second to render. So I guess it would not help much with the former. Not sure how many client apps would play along with the redirect either ? My understanding is that the header-write trick Andrea mentioned during our retreat should in theory work, it's just that none of the containers let us do it? How about we propose patches for Jetty and Tomcat that allow headers to be flushed ? I skimmed through the final draft of the 3.0 servlet spec, looks like they still intend to gather all the headers before sending anything to the client, so there is nobody is going to do this for us anytime soon. 256Mb RAM and documentation is all good, but this problem presumably increases with the number of users. The perceived performance and reliability boost could be substantial too. -Arne Gabriel Roldan wrote: > 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 >> >> > > > -- Arne Kepp 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
