On Fri, May 13, 2011 at 4:42 PM, Gabriel Roldán <[email protected]> wrote: > Hi Andrea, > yes, the reason for calling the dispatcher instead of using > WebMapService directly is that gwc requests don't run our of > control-flow control. > Unfortunately this has always been the case and hence I thought it was > alright and never really dig deep into how well they were interacting.
Yep, the difference is that GWC using its own protocols enters in the dispatcher only when computing the missing tiles (so just once) whilst the direct WMS integration makes it enter the dispatcher twice, nesting two requests one inside the other. > I see you provided a fix already that looks great, cool. There's perhaps > one more thing that we could do to cover all the cases. > The way ControlFlowCallBack is set up right now, still assumes that that > any nested dispatcher request will come from the same thread. More or less. The thing is, the bug was happening exacly because the two requests were coming from the same thread, if they would have come from two different threads they would not have been able to step on each other toes and cause the bug. > That holds > true for the gwc "cache miss" case. I wonder though what's up with > possible dispatcher calls issued by a separate thread? > I don't think GWC will do that right now, because the only case when > it's going to spawn new threads is upon a seed request, and then each of > them calling on the dispatcher will get it's own set of FlowControllers. > But in the eventual case that a thread that already passed the door and > then spawns new threads those one might be out of control? (like in if > gwc with integrated WMS spawned new threads to fetch individual > metatiles for a more agressive caching). > As said, that's not what happens right now, but I guess there'd be a > really easy way of preventing that from the start, which would be to use > an InheritableThreadLocal[1] instead of a simple ThreadLocal to hold > REQUEST_CONTROLLERS? Not so sure. This will be a good idea only if you dynamically create new child threads on demand, but if you rely on a stable thread pool those threads are nobody else's child (they are child of the thread that created the pool in fact) so the inheritable thread local stops working Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
