tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Remaining Tomcat 3.3 Issues
Date Thu, 13 Sep 2001 22:12:11 GMT
Re. 7) Since there is only one facade per Request and only one Request per
thread, you could avoid synchronized all together by having an instance of
SimpleDateFormat in either the Request or the facade.  That would just leave
ServerCookie using DateTool, where the hit would be minimal.  Just me $0.02.
----- Original Message -----
From: "Larry Isaacs" <Larry.Isaacs@sas.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Thursday, September 13, 2001 12:57 PM
Subject: RE: Remaining Tomcat 3.3 Issues


>
>
> > -----Original Message-----
> > From: GOMEZ Henri [mailto:hgomez@slib.fr]
> > Sent: Thursday, September 13, 2001 3:14 PM
> > To: tomcat-dev@jakarta.apache.org
> > 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 ?
>
> My initial preference is in DateTool. However, I may be
> unaware of some pro's or con's.
>
> >
> > >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.
>
> >
> > >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.
>
> I'll take this as a vote to remove the shutdown support from Ajp13
> and not provide an option.  I'm not sure if you are implying
> additional changes by your statement "shutdown from a distant
> machine is dangerous".
>
> >
> > >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 ?
>
> I need CRLF for building on Windows.  It appears that some files
> were checked in from *nix containing CR's that were not stripped
> during the commit.  When I checkout or update from Windows, CVS
> still adds a CR in front of all LFs.  The result is CRCRLF which
> Dev Studio wants to fix.  I'd just like the source to be "clean"
> for final release.  I'm not sure what happens on *nix systems when
> they encounter a CR.
>
> >
> > >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
>
> I'm +1 for user configurability.  I would prefer strict compliance to
> be the default.
>
> >
> >
> > >111   after httpd reload mod_jk fails to find a worker BugRat Repo
> >
> > Didn't know this one but must be easy to handle....
>
> I assume this is likely fixed since the bug is very old.  I just
> prefer someone more familiar with the history of mod_jk to say
> so.
>
> >
> >
> > >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.
>
> 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.
>
> >
> > >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.
>
> >
> > >2927  Nor Oth PC danmil@shore.net NEW
> > >ArrayIndexOutOfBoundsException when
> > >      accessing ajp13
> >
> > I take care of this....
> >
>
> If this is complicated or potentially unsafe, I'm fine with
> resolving as "wontfix".
>
> Larry
>
>


*----*

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