You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by GOMEZ Henri <hg...@slib.fr> on 2001/05/10 21:32:34 UTC
[PROPOSAL AJP14] AJP13 Evolution - Second Pass
Find attached the modified AJP14 proposal which include
the remarks and request from the list.
Nota :
The launch of Tomcat JVM by the mod_jk/jakarta-connector
is not covered since we speak here only about protocol.
That feature is something asked by many JServ users and
may be added later in the native part, at least in
Apache 1.3/2.0 mode. I'm not sure how it can be done
when using IIS or NES.
The automatic context update was an interesting subject
and how we can have these kind of admin informations raised
more questions than answers.
Opening alternate sockets (control socket) we'll load more
the web-server with more opened sockets :
on forked environnement (ie Apache 1.3), 2 x forked (1 data + 1 admin)
on threaded environnement (ie Apache 2.0), 1 x forked (x threaded data + 1
admin)
A solution could be to use the URGENT DATA mode of TCP/IP socket but I'm not
sure it's supported now in JDK 1.1/1.2/1.3....
Another solution is to delay the automatic update mode.
AJP14 have provision on NEGOCIATION phase to disactivate this feature.
But we still need to know when a context is DOWN and later UP.
* A lazy solution could be to have the servlet engine drop all
AJP connections at each update of context (UP/DOWN).
The web servlet will have then to re-open the connection and
will received the UPDATED context list.
* Another solution will be having the servlet engine sending
a 'Context XXX Down' reply when the user send a request against
a DOWN context. The servlet engine could then route the
request to another engine (in LB mode), or to indicate
the failure (in simple servlet engine mode).
And when a context is marked DOWN, we need to know when it's UP again.
Brute mode :
the web-server continue to forward the requests to the servlet engine,
and if it receive the 'Context XXX Down', it try another route.
Clean mode :
the web-server send a 'Context XXX Status' request, check if the reply is
'Context XXX Up', and if still down, try another route. This mode could be
tuned. ie for a down context, ask for status each 10 or 50 requests.
The context UP/DOWN is really a rare case, and we mustn't spend to much time
in handling this type of event. The protocol must keep its speed.
Another feature I'd like to have in mod_jk/jakarta-connector and present in
mod_jserv
is the backup mode :
- In standard mode, a request is routed to only one servlet-engine (using a
know worker).
- In load balancing mode, a request is sent to a pool of servlet-engine,
using a load
factor.
- We miss a backup mode, where all requests goes allways to the same servlet
engine
until the connection is broken (maybe the remote engine is down or network
link
closed). We define then one (or more) alternate engines to handle
requests.
In that mode, the web-servlet will try to detect later if the principal
servlet
engine is up each N requests (or after M seconds...)
-
Henri Gomez ___[_]____
EMAIL : hgomez@slib.fr (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
Posted by kevin seguin <se...@motive.com>.
> > i'm going to go with the "get it to work first, optimize it later"
> > approach :)
>
> Good, as long as you remember you're going to do the "later" part :-)
>
> This is one of the critical pieces in the container performance.
>
in looking at MessageBytes and the rest of the
org.apache.tomcat.util.buf package, it seems that the entire package
could be lifted out of tomcat 3.3. without a problem. unless i missed
something, it only depends on one other tomcat internal, StringManager.
seems like this package would be an important part of optimization (lazy
eval)... true?
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
Posted by cm...@yahoo.com.
On Thu, 10 May 2001, kevin seguin wrote:
>
> > 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 ).
> >
>
> i'm going to go with the "get it to work first, optimize it later"
> approach :)
Good, as long as you remember you're going to do the "later" part :-)
This is one of the critical pieces in the container performance.
Costin
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
Posted by kevin seguin <se...@motive.com>.
> 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 ).
>
i'm going to go with the "get it to work first, optimize it later"
approach :)
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
Posted by cm...@yahoo.com.
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
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
Posted by kevin seguin <se...@motive.com>.
> BTW, we'll need to discuss about the Java side - so
> optimizations on the "lower" level would work on any container.
>
> At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent
> ( i.e. recyclable, low overhead, etc ), and a simple Request object that
> can be easily adapted to TC3.3 and TC4.0.
>
> 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 :)
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.
are you thinking this would be the right thing to do? seems like you
might be suggesting multiple ajp13 implementations for multiple servlet
containers.
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?
Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
Posted by cm...@yahoo.com.
+1
I'll try to implement the Java side as you go with the C changes,
unless someone else volunteers ( jasper is taking more than
I expected, and xalan has a release planned in few weeks ).
BTW, we'll need to discuss about the Java side - so
optimizations on the "lower" level would work on any container.
At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent
( i.e. recyclable, low overhead, etc ), and a simple Request object that
can be easily adapted to TC3.3 and TC4.0.
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 ).
Costin
On Thu, 10 May 2001, GOMEZ Henri wrote:
> Find attached the modified AJP14 proposal which include
> the remarks and request from the list.
>
> Nota :
>
> The launch of Tomcat JVM by the mod_jk/jakarta-connector
> is not covered since we speak here only about protocol.
> That feature is something asked by many JServ users and
> may be added later in the native part, at least in
> Apache 1.3/2.0 mode. I'm not sure how it can be done
> when using IIS or NES.
>
> The automatic context update was an interesting subject
> and how we can have these kind of admin informations raised
> more questions than answers.
>
> Opening alternate sockets (control socket) we'll load more
> the web-server with more opened sockets :
>
> on forked environnement (ie Apache 1.3), 2 x forked (1 data + 1 admin)
> on threaded environnement (ie Apache 2.0), 1 x forked (x threaded data + 1
> admin)
>
> A solution could be to use the URGENT DATA mode of TCP/IP socket but I'm not
> sure it's supported now in JDK 1.1/1.2/1.3....
>
> Another solution is to delay the automatic update mode.
> AJP14 have provision on NEGOCIATION phase to disactivate this feature.
>
> But we still need to know when a context is DOWN and later UP.
>
> * A lazy solution could be to have the servlet engine drop all
> AJP connections at each update of context (UP/DOWN).
>
> The web servlet will have then to re-open the connection and
> will received the UPDATED context list.
>
> * Another solution will be having the servlet engine sending
> a 'Context XXX Down' reply when the user send a request against
> a DOWN context. The servlet engine could then route the
> request to another engine (in LB mode), or to indicate
> the failure (in simple servlet engine mode).
>
> And when a context is marked DOWN, we need to know when it's UP again.
>
> Brute mode :
> the web-server continue to forward the requests to the servlet engine,
> and if it receive the 'Context XXX Down', it try another route.
>
> Clean mode :
> the web-server send a 'Context XXX Status' request, check if the reply is
> 'Context XXX Up', and if still down, try another route. This mode could be
> tuned. ie for a down context, ask for status each 10 or 50 requests.
>
> The context UP/DOWN is really a rare case, and we mustn't spend to much time
> in handling this type of event. The protocol must keep its speed.
>
> Another feature I'd like to have in mod_jk/jakarta-connector and present in
> mod_jserv
> is the backup mode :
>
> - In standard mode, a request is routed to only one servlet-engine (using a
> know worker).
>
> - In load balancing mode, a request is sent to a pool of servlet-engine,
> using a load
> factor.
>
> - We miss a backup mode, where all requests goes allways to the same servlet
> engine
> until the connection is broken (maybe the remote engine is down or network
> link
> closed). We define then one (or more) alternate engines to handle
> requests.
> In that mode, the web-servlet will try to detect later if the principal
> servlet
> engine is up each N requests (or after M seconds...)
>
> -
> Henri Gomez ___[_]____
> EMAIL : hgomez@slib.fr (. .)
> PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>