well done Andrea. Your ideas about which formats they apply to seems to reflect a variety of different reasons for doing this work - illustrating perhaps how important it is.
These reasons include: 1) making sure the server is robust - doesnt fail with OOM or something and deliver the wrong thing or fail to deliver legitimate requests 2) protection against DOS (though I think this needs to happen at a different level ) 3) stopping one user breaking the ability to serve others 4) sharing the resources between different requests to gracefully degrade in performance 5) protecting the client from doing something silly (this is the role of maxfeatures) Some formats - particualr those which are streamable, are logically consistent with a large transfer that may be allowed to take some time and be throttled to share resources around. Others, like raster formats only really make sense as a whole. So, I think your solution sounds like a very good pragmatic one. I'd be keen to have your analysis of the different reasons (what have I missed) and how the various available solutions stacks up against these. This ought to become a "whitepaper" or tutorial or something, but IMHO having this in an accessible form makes the product look a lot more interesting from a risk-averse deployer's perspective. Rob On Thu, May 28, 2009 at 11:22 PM, Andrea Aime <aa...@opengeo.org> wrote: > Hi, > if anybody is interested in trying them out, I've applied > the above two patches on both branches. > If you want to test them in 1.7.x have a look at these > jira for details on how to enable them, if you're playing > on trunk just go to the WMS configuration and use the UI. > http://jira.codehaus.org/browse/GEOS-3085 > http://jira.codehaus.org/browse/GEOS-3086 > > The limits have been applied on raster output only, since > they are the ones where the two are the most important > and easier to control, too. > > There are other WMS outputs: KML, PDF, SVG, Atom, RSS. > > KML, SVG, RSS are streaming, so memory control does not > seem to make much sense. I'm dubious as timeout is concerned > as well, since in these formats the time it takes to > execute the command includes streaming out the result, > which is dependent on the client download speed. > I would say, let's not apply any limit on those. > > PDF and SVG are harder to deal with. They both > build the response in memory before sending it, but > it's not possible to estimate how big it will be. > Time wise, it's possible to determine a rendering > time for both, and it's typically a long longer > than raster rendering. Not sure if we want to > limit it? > Gabriel suggested that for these formats we could > introduce a max number of features rendered. I could > go for that, but wouldn't the limit have to be global > (that is, include raster rendering as well?). > And how would a client know that the limit is > surpassed? > > Opinions? > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
