tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Mod_jk v/s mod_webapp
Date Tue, 02 Apr 2002 16:53:15 GMT
On Tue, 2 Apr 2002, GOMEZ Henri wrote:

> >> Thank Constin,that really helped. Are there any
> >> advantages of WARP over APJ? I mean why would I want
> >> to use one over the other?

The protocol difference is not significant - both are encoding
strings and ints in an efficient ( but non-standard ) way, 
and use similar protocol semantics. 

There are few differences at the API level ( i.e. the number
and content of the message ), with ajp sending fewer packets,
but that's unrelated with the wire protocol.

Now, the big question is if there is really any advantage 
in using WARP/AJP over a standard encoding like XDR. My 
current opinion is _no_, it was a mistake to invent our
own protocol.

It is true that AJP and WARP are a bit more 'compact', and that 
means less data. I highly doubt this plays any real role. 

> Did there is advantages to use warp over ajp ?
> Hard to tell but the question is elsewhere, advantage of
> mod_warp over mod_jk.

Actually I don't think mod_webapp or mod_jk has any inherent 
advantage. Yes, jk is more mature and has loadbalancing and more server
support - but this can be implemented in webapp (or anything else ) as 

It's just a matter of people - jk had many developers contributing to
it, more than any other tomcat component ( AFAIK ). It's also a matter
of evolution - mod_jk started by implementing the ajp12 protocol 
and beeing backward compatible with mod_jserv ( actually a lot 
of code has been refactored from it ). You can still use mod_jserv
with 3.x, and you can use mod_jk with anything from jserv to tomcat4.
Throwing it away and starting from scratch was a big mistake
IMHO, and making webapp specific to tomcat4.0 / APR / etc was
a bigger one. 

> I take a look at XDR (didn't know where to find info about CDR).
> ajp13 is very similar to XDR, and even less bd/cpu cosuming 
> since XDR want to have 4 bytes (32bits) padded messages whereas
> ajp13 could use only single byte. Why waste cycle to send unused
> bytes and waste cycles to decode unused bytes. ;)

CDR is part of IIOP, part of Corba spec. 

Some would argue that 4 bytes alligned structures are more efficient
to process on 32-bit processors. 

For now we'll definitely stay with ajp13, but long term I would rather
use a standard encoding and protocol - if the penalty is reasonably

> Yes, it's clear that a full protocol like IIOP/DCOM is something
> like using a tank to kill a fly, at least in 99% of time operation
> which is to forward request and replies.

NFS is also 99% sending files, and has similar performance needs.

I agree IIOP/DCOM are overkill, and the full XDR/RPC is too much.
But using a subset may be worth it.

> May be we could/should add doc on ajp13 format like the one in
> XDR (RFC 1832) :

Great, check it in :-)

> ...

( but keep it to what we have - i.e. strings/ints/arrays )


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message