Gabriel Roldan ha scritto: > 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.
Neither I do, the issue is that the clients drops the connection but the server does not notice. There are 6 real connections there and 34 ones that we're working on for nothing. The issue here is that a single client can push GeoServer to use a ton of memory when zooming/scrolling a lot. > The actual problem, from a robustness/reliability pov, of giving up on > no longer needed requests is an amazing challenge though. Indeed. > 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. I'm all ears (eyes, whatever) > 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. Right. The main issue is, how do we check on the incoming connection? Because if we can, we can just tap that into a renderer listener and stop the rendering without the need to create our own job queue. It would be similar to the timeout listener we have now, it creates a timer that triggers the end of rendering, it's self contained and quite simple, at least to me: https://svn.codehaus.org/geoserver/trunk/src/wms/src/main/java/org/vfny/geoserver/wms/responses/RenderingTimeoutEnforcer.java > 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. I see... not sure if WMS clients handle redirects transparently, it something we'd have to check. Also, if the client is behind a high latency connection, it might take some time before the redirected request jumps on the new URL, finding the right timing for such control could be tricky. A solution that allows us to check the connection status every 100ms or less would be better, it took me a split second to bring GS to use 40 connection by rolling my mouse scroller and thus zooming in rapidly. We'd also have to redo part of the the dispatcher, at the moment it's linear and in control of how response is setup. But yes, if we can't find a simpler solution and we get resourcing to host such a change, sure, why not Cheers Andrea -- Andrea Aime 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
