tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Anderson" <MMAND...@novell.com>
Subject Re: Remaining Tomcat 3.3 Issues
Date Fri, 14 Sep 2001 16:11:14 GMT
You can hunt me down, just use tranquilizers when you find me :-)

All of the modifications for "graceful restart" were done in the 3.3 codebase.
Most of them were done by Henri Gomez.  I just put in a couple of patches 
for error conditions.  3.2.x still doesn't have these fixes in them, but they
have been ported to JTC (from what I can see looking at the code.)  Do
we want to back port them to 3.2.x or just use JTC once 3.3 is released?

Mike Anderson

>>> wbarker@wilshire.com 09/13/01 02:01PM >>>
I don't think they ever got back-ported to 3.2.x, but I don't know for sure.
The files include:
mod_jk.c[R1.9],jk_ajp13_worker.c[R1.8].

You'll have to hunt down Mike Anderson for the details.  I just remember the
commits.
----- Original Message -----
From: "Larry Isaacs" <Larry.Isaacs@sas.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Thursday, September 13, 2001 1:06 PM
Subject: RE: Remaining Tomcat 3.3 Issues


> Thanks.  Do you know if just 3.3 was affected
> or 3.2.x as well?  If you can give me a clue as to
> what was changed, I can try to determine this.
>
> Larry
>
> > -----Original Message-----
> > From: Bill Barker [mailto:wbarker@wilshire.com] 
> > Sent: Thursday, September 13, 2001 3:15 PM
> > To: tomcat-dev@jakarta.apache.org 
> > Subject: Re: Remaining Tomcat 3.3 Issues
> >
> >
> > I interpreted #111 to be the "graceful restart" clean-up
> > problem that was
> > fixed some months ago.
> > ----- Original Message -----
> > From: "GOMEZ Henri" <hgomez@slib.fr>
> > To: <tomcat-dev@jakarta.apache.org>
> > Sent: Thursday, September 13, 2001 12:13 PM
> > Subject: RE: Remaining Tomcat 3.3 Issues
> >
> >
> > > >7. Evaluate whether anything should be done to deal with the use of
> > > >non-thread-safe DateFormat and related classes.
> > >
> > > The "Date" used in Http10 connector response, is allready
> > > handled by stuff I commited some time ago which use a speed hack
> > > and return allready processed date String if it was processed
> > > in the same second removing need to use SimpeDateFormat at each hit.
> > >
> > > format1123() in org\apache\tomcat\util\buf\DateTool
> > >
> > > But the request.getDateHeader("Date") in facade is still
> > > using DateTool.parseDate(value) in DateTool which need
> > > to be synchronized.
> > >
> > > Question: should we sync in facade or in DateTool ?
> > >
> > > >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
> > >
> > > >8. We need to remove or optionally disable the shutdown support in
> > > >Ajp13Interceptor.  This allows configuring a password protected
> > > >Ajp12Interceptor shutdown to be the only shutdown available.
> > >
> > > Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous.
> > > We should use Ajp13 as link between web-server and tomcat and
> > > use Ajp12 accepting only from localhost.
> > >
> > > >9. Some files under src/native have embedded CR's, i.e. Unix
> > > >files would have
> > > >CRLF and Windows files would have CRCRLF's.  These need to
> > be fixed.
> > >
> > > Couldn't we say that ALL src in native will be only in Unix mode ?
> > >
> > > >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 :
> > >
> > > JkOptions +ForwardUnparsedURI => strict spec respect
> > > JkOptions -ForwardUnparsedURI => rewrite compatibility
> > >
> > >
> > > >111   after httpd reload mod_jk fails to find a worker BugRat Repo
> > >
> > > Didn't know this one but must be easy to handle....
> > >
> > >
> > > >2333  Nor Oth PC hgomez@slib.fr NEW  HTTP Reason will be
> > > >destroyed in header
> > > >      using AJP12
> > >
> > > Some patch was sent some time ago and even if AJP12 is somewhat
> > > deprecated, I should try to commit the provided patch.
> > >
> > > >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)
> > >
> > > >2927  Nor Oth PC danmil@shore.net NEW
> > > >ArrayIndexOutOfBoundsException when
> > > >      accessing ajp13
> > >
> > > I take care of this....
> > >
> > > >I will update the RELEASE-PLAN-3.3 tomorrow with the previous
> > > >schedule and these issues, updating as needed base on discussion
> > > >that occurs before then. These issues are the driving force for
> > > >when RC1 and RC2 can be built and posted.  The dates previously
> > > >voted on are still the targets, but may slip as needed to deal
> > > >with these issues.
> > >
> > > >I plan to go through (possibly with some help) all the
> > Tomcat3 bugs.
> > > >Where I find bugs for earlier Tomcat's that have not been addressed
> > > >for Tomcat 3.3, I will do what I can to address them.  I
> > will prepare
> > > >and post a list of all bugs and there status in Tomcat 3.3.  If
> > > >I don't have this list ready prior to RC2, I will still build and
> > > >post RC2, but will not start the 7 day voting deadline clock until
> > > >this list is posted.
> > > >
> > > >If a showstopper appears from this scan (which I don't expect
> > > >to happen)
> > > >I will post this issue and plan on another release candidate.
> > >
> > > Let's go....
> > >
> > >
> >
> >
> > *----*
> >
> > This message is intended only for the use of the person(s)
> > listed above
> > as the intended recipient(s), and may contain information that is
> > PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient,
> > you may not read, copy, or distribute this message or any
> > attachment.
> > If you received this communication in error, please notify us
> > immediately
> > by e-mail and then delete all copies of this message and any
> > attachments.
> >
> >
> > In addition you should be aware that ordinary (unencrypted)
> > e-mail sent
> > through the Internet is not secure. Do not send confidential
> > or sensitive
> > information, such as social security numbers, account
> > numbers, personal
> > identification numbers and passwords, to us via ordinary
> > (unencrypted)
> > e-mail.
> >
>
>


*----*

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

Mime
View raw message