Under i5/OS, the IBM HTTP server use Apache but with a different strategy. >From the IBM documentation (SG246716)
"The HTTP Server (powered by Apache) has its own multi-process model. Each HTTP server starts two (or three) processes under the QHTTPSVR subsystem: The manager process The primary process The backup process, when configured with the HotBackup directive Each child process maintains its own thread pool independently. " ... "Tip: Asynchronous I/O is one of many enhancements to the standard Apache server as delivered to IBM Rochester by the Apache Software Foundation (ASF). This is just one of the many reasons that the parenthetical phrase (powered by Apache) means integration. " It's really an IBM HTTP server powered by Apache. 2009/5/12 Rainer Jung <rainer.j...@kippdata.de>: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
