tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject RE: Remaining Tomcat 3.3 Issues
Date Fri, 14 Sep 2001 23:02:56 GMT
>>> >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 hgomez@slib.fr 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 danmil@shore.net NEW  
>>> >ArrayIndexOutOfBoundsException when
>>> >      accessing ajp13  

Fixed...

Mime
View raw message