>>> >1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
>>>
>>> This one is very difficult to reproduce (I never succeed).
>>> We need more information on configuration. May be related with
>>> CHUNKED. I'd like to see bug reporter to test against latest TC 3.3
>>
>>Did your attempts include 3.2.2 or 3.2.3. If so, I'll resolve the
>>bug reports as "worksforme". Otherwise, I'll just add a note that
>>it couldn't be reproduced in 3.3 and is assumed fixed.
I couldn't reproduce the problem even after stressed the TC 3.3
from CVS with ab (ApacheBench). I've use a servlet with a sleep time
of 3 seconds to simul a slow responding servlet and launch ab
for 10000 requests with 100 and then 200 concurrents access without
problems. The only problems I've got is that a some time, when
I increase the concurrent to 300, Apache refuse to allocate more
than 250 childs (that's the standard Apache 1.3 config)
I ask bugs reported to make another test with up to date TC 3.3
>>> >11. Make sure we are okay with mod_jk not supporting
>>Apache's rewrite
>>> >in Tomcat 3.3's mod_jk. I'm fine with not supporting it,
>but I want
>>> >to include some justification in the documentation to avoid some of
>>> >the "why don't you" questions.
>>>
>>> As said Costin, making mod_jk using uri or unparsed_uri is not
>>> difficult, but we have here 2 situations. Strict respect of spec
>>> (unparsed) or mod_rewrite compatibility.
>>>
>>> Why not let the final user decide and create a new JkOptions
>>directive
>>> (easy). ie :
>>>
I've added JkOptions directive to mod_jk in JT and JTC :
JkOptions +ForwardUnparsedURI => strict spec respect
JkOptions -ForwardUnparsedURI => rewrite compatibility
>>> >111 after httpd reload mod_jk fails to find a worker
>BugRat Repo
Fixed on 3.3
>>> >2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be
>>> >destroyed in header
>>> > using AJP12
>>>
To be fixed
>>I scanned but didn't have much time assess applying the
>>supplied patch. My main reservation is that I'm not sure if
>>IIS or netscape is multi-threaded, in which case the
>>static buffer could do more harm than good.
Ditto
>>> >2550 Ajp13 Connection hanging on static content.
>>>
>>> Should take a look at this one even. Majority of users
>>> use Apache to handle static data but it must be investigated
>>> (I)
>>
>>My understanding is that Ajp13 keeps the connection open,
>>so a "Connection reset by peer" sounds bad to me. Do you know
>>if this issue might have been fixed since the bug was opened?
>>I though there was some work on re-establishing the connection.
Didn't got any problems, with Netscape Browser and mod_jk using
JkMount /examples/* ajp13
>>> >2927 Nor Oth PC [EMAIL PROTECTED] NEW
>>> >ArrayIndexOutOfBoundsException when
>>> > accessing ajp13
Fixed...
