On 12.05.2009 15:57, Henri Gomez wrote: >> On 12.05.2009 15:31, Henri Gomez wrote: >>> I see you take a similar approach :) >> Yes, but based on your analysis. >> > > I works :) > > If nobody object, you should commit it, static variable, apr_pool on a > multi-threaded application, it's evil ;-(
I will. But it's still unclear, why multiple threads should call it. The whole initialization is done single threaded, and i remember the only other i5 related problem we had, when the life cycle of one of the pools was different. So it may be more related to the way the double initialization of httpd is done on i5 and not directly to concurrency. Nevertheless i think the local variable is cleaner/safer unless jk_resolve() sometimes moves into the performence critical path, where we might then switch to the global variable bt then also using correct locking. The pool clean was introduced last October in http://svn.eu.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_connect.c?r1=706039&r2=745136&diff_format=h Don't know exactly, what was Mladens motivation for it, but the locally created and destroyed pool will release resources as well. Thanks for reporting and breaking it down to jk_resolve() and the pool. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
