[EMAIL PROTECTED] wrote:
>
> If you can clarify your concerns - do you disagree with Coyote
> entirely ( and why ), is it something missing that you want
> added or something that is there and you feel shouldn't ?
>
Fair enough. I think part of the problem is that one
of the primary goals of the proposal appears to be to
find common ground between the Tomcat 3 and Tomcat 4
camps. I have the sneaking suspicion that the code should
be the primary concern.
A straw-man proposal might help to clarify my worries.
(it's not a real proposal, I'm looking to be told what
my incorrect assumptions are)
From the standpoint of supporting the 2.4 spec (totally
ignoring the 3/4 thing), it seems like this might make
more sense:
- A represenative set of benchmarks is agreed upon,
in advance, and tests are run to determine what
Tomcat 4 performance is like now, where the
bottlenecks are (based on profiling, not intuition),
and performance goals are set for Tomcat 5. What
needs to be faster? Static file serving? HelloWorld?
JSP's? How much faster? Exactly? etc, etc.
- The most ugly bits of Tomcat 4 are listed, and a
subset of them is set aside to be fixed. I've chosen
the startup code and tomcat events/listeners as my
biggest concerns for this straw-man, but I'm sure
there are others. It's mainly the process of choosing
actual, concrete problems (instead of generalities)
that I think it important.
- Tomcat 5 is Tomcat 4 with lots of cleanup work and
modifications for whatever the 2.4 spec comes up
with. There are no major architectural changes. OTOH,
the 2.4 spec could be bizarre, in which case all bets
are off :-)
- Coyote is not part of Tomcat 5. Instead, Tomcat 5
moves to having 2 (and only 2) connectors that are
single-purpose no-compromise performance demons:
- A special-purpose HTTP connector built to take
full advantage of Tomcat 4, with a few layers
of abstraction as possible, using the existing
o.a.c.Connector API. This results in the smallest,
fasted code possible.
- A special-purpose AJP connector. Again, single
purpose, build for Tomcat 5 only, using the
existing o.a.c.Connector API, and again,this
results in the least possible amount of code.
- Other connectors can be implement in j-t-c as
needed, maybe as Coyote. Experiments like JNI, etc
shouldn't be a consideration for the core Tomcat 5
design. There should probably also be some work
with the NIO api's non-blocking stuff, ala what
Greg Wilkins has done with Jetty, but again this
is non-core.
- Tomcat 5 cleans up the current startup spaghetti
by going through each and every Tomcat event listener
and deciding if it needs to be made into a real,
explicitly called API. Listeners should be hooks
for extensions, making them them implement core
functionality makes for a tangled mass of pointers
and a very confusing startup sequence. Pretty much
everything but the management listeners need to go.
After most of the listeners are removed, the set
of Tomcat events is rationalized and documented.
This is a big deal. This code is an undocumented
mess.
- There are places where the Standard* classes make
ugly assumptions about one another. This needs to
be examined on a case-by-case basis, and most of
the really ugly stuff needs to be removed, or the
assumptions need to be made into real method calls
in the top-level interfaces.
- Other stuff, but since this is a straw man only,
I think you get the idea.
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
