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 well. 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 small. > 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 :-) > 1. AJP13 DATA TYPES > ... ( but keep it to what we have - i.e. strings/ints/arrays ) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
