On Thu, 13 Sep 2001, Bill Barker wrote:
> 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.
+1
Costin
> ----- Original Message -----
> From: "Larry Isaacs" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, September 13, 2001 12:57 PM
> Subject: RE: Remaining Tomcat 3.3 Issues
>
>
> >
> >
> > > -----Original Message-----
> > > From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, September 13, 2001 3:14 PM
> > > To: [EMAIL PROTECTED]
> > > 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
>
