Question on JTC native/apache2.0 mod_jk.c

[Larry Isaacs <La...@sas.com>]

I tracked down the source of the hang I was seeing
running Tomcat 3.3's internal test with Apache 2.0.
It turns out the native/Apache2.0 mod_jk.c code:

....
    /* Use per/thread pool ( or "context" ) to reuse the 
       endpoint. It's a bit faster, but I don't know 
       how to deal with load balancing - but it's usefull for JNI
    */

#ifdef REUSE_WORKER
    apr_pool_t *rpool=r->pool;
    apr_pool_t *parent_pool= apr_pool_get_parent( rpool );
    apr_pool_t *tpool= apr_pool_get_parent( parent_pool );

    apr_pool_userdata_get( (void **)&end, "jk_thread_endpoint", tpool );
...

doesn't yield a thread unique "tpool".  I didn't have time
to study Apache 2.0 much.  My current guess is that "tpool"
is really Apache "child" unique instead of thread unique.
On systems where child = thread, it works.  On windows,
Apache defaults to starting one child that uses 250 threads.
As a result, the "test" requests try to use the same connection
that is trying to read the results for test.jsp leading to the
hang.

I think it would be best to programmatically determine if
"tpool" is usable to fetch a thread unique endpoint, and
do something appropriate if it is not.  Before I go digging
into Apache 2.0 code, I would appreciate any suggestions or
words of wisdom that might speed the process.  Thanks.

Cheers,
Larry


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Question on JTC native/apache2.0 mod_jk.c

[co...@covalent.net]

On Tue, 7 May 2002, Larry Isaacs wrote:

> #ifdef REUSE_WORKER

> I think it would be best to programmatically determine if
> "tpool" is usable to fetch a thread unique endpoint, and
> do something appropriate if it is not.  Before I go digging
> into Apache 2.0 code, I would appreciate any suggestions or
> words of wisdom that might speed the process.  Thanks.

I think it's better to just undefine REUSE_WORKER ( and/or 
remove the code ).

It is just a way to avoid few allocations and/or mutexes,
there is no proof that this has any effect on performance
( and it shouldn't - compared with the socket operations
this is nothing ).

Note that the endpoint will still be recycled - this is 
just to use per-thread data for the objects used in 
processing the request.


Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>