On Thu, 10 May 2001, kevin seguin wrote:
> > This is not the "easiest" solution - from my point of view the easisest
> > would be to just write the Ajp14Interceptor and use the existing and
> > optimized 3.3 infrastructure. ( and use a reimplementation of the protocol
> > for 4.0 - using their low-level objects ).
> >
>
> i'm not 100% sure i understand what you're saying, but i'm pretty sure
> you're talking about something i've been thinking about :)
I hope I'm talking about what I'm thinking, and the reverse :-)
> in tc 3.x, the ajp stuff uses core tomcat classes like MessageBytes,
> OutputBuffer, Request, etc.. for my ajp13 implementation for tc 4, i
> removed refs to tc 3 classes, and used tc 4 classes where i could (i.e.
> HttpRequestBase).
>
> i was thinking that versions of MessageBytes, OutputBuffer, Request (and
> Response??), and other classes might find their way into
> jakarta-tomcat-connector, so they could be used with ajp code across
> different versions of different servlet containers.
Yes, that would be probably the best - as all those classes are quite well
tuned.
Most of tomcat3.3 performance comes from those 5-6 classes - and the fact
that we use lazy evaluation in many cases. ( there are few other tricks in
some modules, but most of the modules and the servlet 22 facade are
mostly the same as in tomct3.1 - i.e. not tuned yet ).
But we know some people have problems with tomcat3.3.
> are you thinking this would be the right thing to do? seems like you
> might be suggesting multiple ajp13 implementations for multiple servlet
> containers.
It would be the right thing to do from a technical point of view.
Politically - I don't know, I don't want to go into another war or argue
about the benefits ( you can read the archives for that :-)
> i think it would be better to have the core ajp13 code separate from
> servlet connector/adapter code. that way, hopefully, you could use the
> same ajp13 core with connectors for tc 3, tc 4, jetty, and so on.
> thoughts?
Again - that would be the right way to go. In most cases ( even for jetty
- I took a quick look at their code ) using an optimized low-level
representation for data will be good for performance.
The whole idea is to avoid expensive operations until they are actually
needed - most servlets don't read all the headers, so there's no need to
create the strings and hash them. ( it's not even needed to convert from
bytes to chars - another expensive operation ).
But having separate adapters for each container is also a valid option.
Costin
