tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Isaacs <Larry.Isa...@sas.com>
Subject Question on JTC native/apache2.0 mod_jk.c
Date Tue, 07 May 2002 12:49:13 GMT
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:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message