tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: mod_jk 1.2.28 on i5/OS
Date Tue, 12 May 2009 14:31:43 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message