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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
