Am 05.08.2009 12:37, schrieb Henri Gomez:
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
Same patches needed to make it works on i5/OS V6R1.
When did a
> 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
>
>
Same patches needed to make it works on i5/OS V6R1.
When did a new release of mod_jk is plann
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 :
> I'll try the new patch today.
>
> Thanks for your time on this !
>
> Le 13
I'll try the new patch today.
Thanks for your time on this !
Le 13 mai 09 à 15:51, Rainer Jung 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 cle
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 t
Gimme a few minutes, there's something non i5-specific wrong with the
patch ...
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) {
>
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;
>
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 referen
Hi Rainer.
The new patch didn't fix it :
User Trace Dump for job 680894/QTMHHTTP/DAPSERVER. Size: 300K, Wrapped
0 times.
--- 05/13/2009 10:35:17 ---
0018:292544 apr_palloc: WARNING --
0018:292568 apr_palloc() called with NULL pool.
0018:292592 requested size
I'll try it tomorrow !
2009/5/12 Rainer Jung :
> Here's the patch keeping the original structure but using a cleanup to
> destroy the pool reference. If it works, I would like that better.
>
> Regards,
>
> Rainer
>
>
> -
> To unsu
Here's the patch keeping the original structure but using a cleanup to
destroy the pool reference. If it works, I would like that better.
Regards,
Rainer
Index: jk_connect.c
===
--- jk_connect.c(revision 763986)
+++ jk_connec
Before committing I gave it a second thought. My theory is motivated by
the crash around main_log we fixed in 2007. There we learned, that on i5
the two initialization passes of httpd are done in the same process. We
also saw, that the pool pconf got invalidated after the first pass. That
was a pro
> 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
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 pr
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 ;-(
> 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 ;-(
---
>>>
>>> Why do you think, is it possible, that multiple threads will enter
>>> jk_resolve() in parallel?
It seems to be the case at least on the i5/OS implementation.
These one is heavily multi-threaded
-
To unsubscribe, e-mail:
On 12.05.2009 15:31, Henri Gomez wrote:
> I see you take a similar approach :)
Yes, but based on your analysis.
> Could you attach the patch file ?
Attached.
> 2009/5/12 Rainer Jung :
>> Hi Henri,
>>
>> can you try the below patch? It replaces the global pool by a function
>> local one, which i
I see you take a similar approach :)
Could you attach the patch file ?
2009/5/12 Rainer Jung :
> Hi Henri,
>
> can you try the below patch? It replaces the global pool by a function
> local one, which is OK, because the resolver calls are not in the
> performance critical path (mostly startup ini
Hi Henri,
can you try the below patch? It replaces the global pool by a function
local one, which is OK, because the resolver calls are not in the
performance critical path (mostly startup initialization and
reconfiguration).
Why do you think, is it possible, that multiple threads will enter
jk_r
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 :
> FYI.
>
> If I comment the apr_pool_clear() call, I didn't get the initialisation error
>
> 2009/5/12 Henri Gomez :
>> Hi to all,
>>
>> I rebu
FYI.
If I comment the apr_pool_clear() call, I didn't get the initialisation error
2009/5/12 Henri Gomez :
> Hi to all,
>
> I rebuild the mod_jk 1.2.28 on our i5/OS and Apache instance failed.
>
> Here is the stack trace :
>
> 0009:259448 Stack: Library / Program Module Stmt
> Pr
Hi to all,
I rebuild the mod_jk 1.2.28 on our i5/OS and Apache instance failed.
Here is the stack trace :
0009:259448 Stack: Library/ Program Module Stmt
Procedure
0009:259488 Stack: QSYS / QCMD455 :
0009:259520 Stack: QHTTPSVR / QZHBMAIN
23 matches
Mail list logo
