I've changed the (new) StreamHandlerFactory to punt on "jar" protocols. If you can build from source, I can tell you how to disable it altogether. You might want to try the 12/26 nightly. Personally, I can't see this doing anything but shortening the stack trace. But then again, I can't see how the inclusion/exclusion of Http10Interceptor can make any difference either.
I'm including the developer list in the reply, in the hopes that someone else can spot what I'm missing. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Bill Barker" <[EMAIL PROTECTED]> Sent: Monday, December 24, 2001 8:13 PM Subject: Re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5390 > Hi Bill, > > Gee, it's xmas eve and we're pounding on the keyboard. Hahaha - or should I > say Hohoho. > > I attached the log -- it's the whole thing because it's just one url > request -- xxx.jsp and every error that went with it until I received a > blank screen response. At the end, tomcat is dead. It will not serve any > more requests. > > Let me tell you where I am. I do have a work around although I cannot > explain why it works! > 1. I started tomcat using a console with the http10 connector. Everything > worked fine using this connector. > 2. I then started up the web server and everything went fine using the ajp12 > and ajp13 connectors. > 3. I then removed the http10 connector still using the web server ajp12/13 > connectors and IT BLEW UP. > 4. I put back the http10 connector back in and only used the ajp12/13 (step > 2) and it works great. > 5. I brought tomcat up as a service and only used the ajp12/13 and it works > great as long as the http10 connector is enabled. > > I repeated these steps for a few hours to make sure everything was > reproducible. It was. > > I put this fix in (enabled the http10 connector on localhost so internet > folks can't use it) on my second test server and it also ran fine. I'm now > doing a stress test on it now for a few hours to make sure everything's cool > before I roll it on the prod server. I'm sure it's going to fly. > > If you can figure this one out, send me your mailing address and I'll send > you some hawaiian chocolate macadamia nuts. Aah, send me your mailing > address anyway and I'll send you some munchies. You've been a real pal. > Merry xmas. > > Aloha my friend and thanks for your help, > Mike > > > ----- Original Message ----- > From: "Bill Barker" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, December 24, 2001 5:33 PM > Subject: Re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5390 > > > It's likely that I'll only be interested in the lines below the presumably > 1000 lines that start java.util.zip, but you can send me the whole log if > you like. Of course, gzipped is better. > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, December 24, 2001 2:48 PM > Subject: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5390 > > > > Yes, it's normal thru the 404 except the 404 never get's returned on the > > response. Instead that monster stack overflow takes over and tomcat goes > > dead (a blank response is sent to the browser). If you'd like to see the > > full 1040+ lines of exception code associated with the log snippet I > posted > > to bugz, I'll be happy to email it to you. This big exception occurs > after > > I type in xxx.jsp after a fresh restart of tomcat. I'm not sure if it was > > cool to post that much stuff to bugz or to continue this discussion as a > > thread. The problem is consistent. As soon as I take out the web.xml > > entries for the jsp, everything runs normal. I'll scale down my test env > to > > tomcat standalone and retest. I've already got the code running on my > > production server and I'm afraid someone is going to try that jsp > > load-onstartup and blow my jvm/tomcat system for my other server users. > > > > I'm in the office now and successfully reproduced the same error on a > second > > tomcat server using the code based from the 12/20 nightly build. Anyway, > do > > you want me to send the big log to you or post it to bugz? > > > > Thanks for all your help and merry xmas. > > Regards, > > Mike > > > > > > ------- Additional Comments From [EMAIL PROTECTED] 2001-12-24 > > 14:03 ------- > > Everything up to the "Status code:404" line is normal, and AFAIK none of > the > > changes to the App-Classloader should be able to cause this. If you can > add > > the log as an attachment, I might be able to track something down, but > since > > my > > simple attempt to reproduce failed to fail I don't have enough info to go > > on. > > > > If you have your own 404 handler, you might also want to check there > > (although > > I can't see how to write one buggy enough to blow up here :). > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
