>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?
I'd really like to have only one connector code base after JT
release, J-T-C, using SNAP to import stuff to 3.2/3.3....
It's just too hard today, and when we have all finished works on
JT mod_jk fixes, we must port them to JTC and then make a
JTC release, tag it or whatever....
>
>Mike Anderson
>
>>>> [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>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:[EMAIL PROTECTED]]
>> > Sent: Thursday, September 13, 2001 3:15 PM
>> > To: [EMAIL PROTECTED]
>> > 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" <[EMAIL PROTECTED]>
>> > To: <[EMAIL PROTECTED]>
>> > 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 [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.
>> > >
>> > > >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 [EMAIL PROTECTED] 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.
>
