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 Tue, 12 May 2009 13:17:09 GMT
I modified the current jk_connect to avoid problem with the static
jk_apr_pool variable and sus avoid concurrency problems.

Study

2009/5/12 Henri Gomez <henri.gomez@gmail.com>:
> FYI.
>
> If I comment the apr_pool_clear() call, I didn't get the initialisation error
>
> 2009/5/12 Henri Gomez <henri.gomez@gmail.com>:
>> Hi to all,
>>
>> I rebuild the mod_jk 1.2.28 on our i5/OS and Apache instance failed.
>>
>> Here is the stack trace :
>>
>> 00000009:259448 Stack:  Library    / Program     Module      Stmt
>> Procedure
>> 00000009:259488 Stack:  QSYS       / QCMD                    455  
:
>> 00000009:259520 Stack:  QHTTPSVR   / QZHBMAIN    ZHBMAIN     0     :
>> _CXX_PEP__Fv
>> 00000009:259552 Stack:  QHTTPSVR   / QZHBMAIN    ZHBMAIN     18    :
>> main
>> 00000009:259576 Stack:  QHTTPSVR   / QZHBMAIN    ZHBMAIN     234   :
>> BigSwitch__FiPPc
>> 00000009:259608 Stack:  QHTTPSVR   / QZSRHTTP    QZSRMAIN    0     :
>> _CXX_PEP__Fv
>> 00000009:259640 Stack:  QHTTPSVR   / QZSRHTTP    QZSRMAIN    2     :
>> main
>> 00000009:267440 Stack:  QHTTPSVR   / QZSRCORE    MAIN        868   :
>> apache_main
>> 00000009:287992 Stack:  QHTTPSVR   / QZSRCORE    HTTP_CONFI  5     :
>> ap_run_post_config
>> 00000009:288288 Stack:  QHTTPSVR   / MOD_JK1228  MOD_JK      60    :
>> jk_post_config
>> 00000009:288320 Stack:  QHTTPSVR   / MOD_JK1228  MOD_JK      35    :
>> init_jk
>> 00000009:288688 Stack:  QHTTPSVR   / MOD_JK1228  JK_WORKER   34    :
>> wc_open
>> 00000009:288720 Stack:  QHTTPSVR   / MOD_JK1228  JK_WORKER   9     :
>> build_worker_map
>> 00000009:296848 Stack:  QHTTPSVR   / MOD_JK1228  JK_WORKER   28    :
>> wc_create_worker
>> 00000009:298192 Stack:  QHTTPSVR   / MOD_JK1228  JK_AJP13_W  5     :
>> validate
>> 00000009:298208 Stack:  QHTTPSVR   / MOD_JK1228  JK_AJP_COM  29    :
>> ajp_validate
>> 00000009:298216 Stack:  QHTTPSVR   / MOD_JK1228  JK_CONNECT  19    :
>> jk_resolve
>> 00000009:316840 Stack:  QHTTPSVR   / QZSRAPR     APR_POOLS   13    :
>> apr_pool_clear
>> 00000009:316864 Stack:  QHTTPSVR   / QZSRAPR     APR_POOLS   8     :
>> allocator_free
>> 00000009:316880 Stack:  QHTTPSVR   / QZSRCORE    MAIN        18    :
>> Main_Excp_Handler
>> 00000009:316888 Stack:  QHTTPSVR   / QZSRAPR     OS400TRACE  7     :
>> apr_dstack_CCSID
>> 00000009:326912 Stack:  QSYS       / QP0ZCPA     QP0ZUDBG    3     :
>> Qp0zDumpStack
>> 00000009:346808 Stack:  QSYS       / QP0ZSCPA    QP0ZSDBG    2     :
>> Qp0zSUDumpStack
>> 00000009:346824 Stack:  QSYS       / QP0ZSCPA    QP0ZSDBG    12    :
>> Qp0zSUDumpTargetStack
>> 00000009:346824 Stack:  Completed
>> 00000009:407280 apr_dump_trace(): dump for job
>> 678302/QTMHHTTP/DAPSERVER
>>                                                 TRCTCPAPP
Output
>>
>> The problem appears in jk_resolve just after apr_pool_create.
>>
>> What happen if 2 threads goes in jk_resolve at the same time ?
>>
>>        if (!jk_apr_pool) {
>>            if (apr_pool_create(&jk_apr_pool, (apr_pool_t *)pool) !=
>> APR_SUCCESS) {
>>                JK_TRACE_EXIT(l);
>>                return JK_FALSE;
>>            }
>>        }
>>        apr_pool_clear(jk_apr_pool);
>>        if (apr_sockaddr_info_get
>>            (&remote_sa, host, APR_UNSPEC, (apr_port_t) port, 0, jk_apr_pool)
>>            != APR_SUCCESS) {
>>            JK_TRACE_EXIT(l);
>>            return JK_FALSE;
>>        }
>>
>


Mime
View raw message