tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmanola...@yahoo.com
Subject Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
Date Thu, 10 May 2001 23:49:33 GMT
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


Mime
View raw message