tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <henri.go...@gmail.com>
Subject Re: mod_jk 1.2.28 on i5/OS
Date Fri, 15 May 2009 10:00:19 GMT
Hi Rainer.

With your latest patch, it seems to works.

May be the problem wasn't in thread collision but just with pool
problem with double inits.

I'll do more tests and so stress load


Regards

>2009/5/14 Henri Gomez <henri.gomez@gmail.com>:
> I'll try the new patch today.
>
> Thanks for your time on this !
>
> Le 13 mai 09 à 15:51, Rainer Jung <rainer.jung@kippdata.de> a écrit :
>
>> Sorry for the broken patch. Besides the not so nice multiple registation
>> of the cleanup, the real problem for the crash after the patch is, that
>> clear() on a pool already calls the cleanup. So I had to register the
>> cleanup for the parent pool (pconf) and not for the pool itself.
>>
>> I'll think about the thread-safety next, but as I said that is not the
>> cause for your crashes.
>>
>> Regards,
>>
>> Rainer
>>
>> On 13.05.2009 14:56, Henri Gomez wrote:
>>>
>>> Some comments on your latest provided patch :
>>>
>>>      if (!jk_resolv_pool) {
>>>           if (apr_pool_create(&jk_resolv_pool, (apr_pool_t *)pool)
>>> != APR_SUCCESS) {
>>>               JK_TRACE_EXIT(l);
>>>               return JK_FALSE;
>>>           }
>>>       }
>>>       /* We need to clear the pool reference, if the pool gets destroyed
>>>                       * via its parent pool. */
>>>       apr_pool_cleanup_register(jk_resolv_pool, &jk_resolv_pool,
>>> jk_resolv_cleanup, jk_resolv_cleanup);
>>>       apr_pool_clear(jk_resolv_pool);
>>>       if (apr_sockaddr_info_get
>>>           (&remote_sa, host, APR_UNSPEC, (apr_port_t) port, 0,
>>> jk_resolv_pool)
>>>           != APR_SUCCESS) {
>>>           JK_TRACE_EXIT(l);
>>>           return JK_FALSE;
>>>       }
>>>
>>> Why not just add the cleanup register in pool create side ?
>>>
>>>      if (!jk_resolv_pool) {
>>>           if (apr_pool_create(&jk_resolv_pool, (apr_pool_t *)pool)
>>> != APR_SUCCESS) {
>>>               JK_TRACE_EXIT(l);
>>>               return JK_FALSE;
>>>           }
>>>
>>>       /* We need to clear the pool reference, if the pool gets destroyed
>>>                       * via its parent pool. */
>>>       apr_pool_cleanup_register(jk_resolv_pool, &jk_resolv_pool,
>>> jk_resolv_cleanup, jk_resolv_cleanup);
>>>       }
>>>
>>>       apr_pool_clear(jk_resolv_pool);
>>>       if (apr_sockaddr_info_get
>>>           (&remote_sa, host, APR_UNSPEC, (apr_port_t) port, 0,
>>> jk_resolv_pool)
>>>           != APR_SUCCESS) {
>>>           JK_TRACE_EXIT(l);
>>>           return JK_FALSE;
>>>       }
>>>
>>>
>>> Also what could happen if we get many threads calling jk_resolv at the
>>> same time ?
>>
>> <jk_connect.patch>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message