Sounds like a perfectly reasonable approach for 1.7.x to me Andrea. +1 on your proposed enhancements.
I'll keep from commenting on the other issues here for the sake of letting you better invest the time given, everything else can be talked about as it's own thread Cheers, Gabriel Andrea Aime wrote: > Justin Deoliveira ha scritto: >> <snip> >>> Time usage >>> ------------------------------------------------- >> <snip> >>> I have some reservations on applying this kind >>> of solution on 1.7.x due to a couple of things: >>> - it always requires two threads per request, >>> one provided by the container that is executing >>> the http request, and another doing the actual >>> rendering in the thread pool >>> - it changes the request is executed even when >>> if the admin did not activate it >>> >>> I was considering a lower tech solution involving >>> the usage of a timer. A timer is started before the >>> rendering starts with the timeout time as its delay. >>> If the rendering terminates within it, the timer >>> is just cancelled. If the timer is activated instead, >>> it calls the stop() method over the renderer, and >>> for good measure it also disposes of the graphics >>> the renderer was using so that coverage rendering >>> is killed as well. >> Do you see the timer as a longer term solution as well? Or when we do >> have a "job queue" do you see this being rolled in. I can see benefits >> to having both bits of functionality separate, or rolled into one. > > I think it can stay in the long term as well, as long > as we don't need to control how many threads each > service is allowed to use, or control their priority > over time (throttling down of long requests). > That is, the solution is simple, but it's not hacky imho, > so it can stay there until we can have resources for > a well rounded process management. > I'm also a bit nervous about having our own process > handling in that never creating your own threads > is one of the rules for big J2EE containers, thought > that was for entity/service beans, and was never > forbidden for pure servlets afaik. > I'm just worried that bigger containers like WebLogic/WebSphere > might have some stringent controls in place that would > trigger if we start keeping our own thread pools. > Timer does use threads as well, but that is so common > that I don't think it would be blocked. > Anyways, I'm just hypothesizing, we'll know better > when we go down that road. > >> <snip> >>> Questions >>> ------------------------------------------------- >>> >>> Justin, to make sure, what's the effort involved >>> into adding an option to the configuration in a way >>> that it goes straight to the services without the >>> need to add it to the UI in 1.7.x? >>> I think it would require changing the xml reader/writer >>> classes, the involved ServiceInfo class, and that would >>> be it, assuming the patch goes down an grab it? >>> I guess if I use the metadata map I would not even need >>> to change the reader/writer classes or the ServiceInfo, >>> but only change the service code, right? >>> >> So on 1.7.x what would be involved (still a bit of a pain to add config >> parameters unfortunately) >> >> 1) add any methods to WMSInfo or other config objects you need (optional >> if you decide to use the metadata map) >> >> 2) Modify LegacyServiceReader or just WMSServiceLoader (depending on >> which classes if any you touch) to read the parameters from the xml >> >> 3) Modify the old XMLConfigWriter to persist the configuration >> >> 4) Flush out any bugs in the current pipeline of metadata properties >> being lost (if you go that route). Remember that when the UI is saved >> all the objects are still wiped out, there could be a couple of issues >> hiding around where metadata entries re not "round tripped" >> >> On trunk in theory step 1) should be the only one necessary. > > Good, thanks for laying this out for me. > > Cheers > Andrea > -- Gabriel Roldan 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 asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
