Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 32067 invoked from network); 2 Apr 2002 12:51:33 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Apr 2002 12:51:33 -0000 Received: (qmail 26322 invoked by uid 97); 2 Apr 2002 12:51:20 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 26303 invoked by uid 97); 2 Apr 2002 12:51:19 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 26292 invoked from network); 2 Apr 2002 12:51:19 -0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Mod_jk v/s mod_webapp X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 2 Apr 2002 14:51:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mod_jk v/s mod_webapp Thread-Index: AcHXShlts7RZlzk2Tu6tOPgLdVCKzQC8JY7Q From: "GOMEZ Henri" To: "Tomcat Developers List" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >> 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? I could tell you that packet encoding in ajp13 and warp is very similar.=20 Did there is advantages to use warp over ajp ? Hard to tell but the question is elsewhere, advantage of mod_warp over mod_jk. mod_warp use warp protocol, require Apache Portable Runtime and is known to works under Apache 1.3/2.0 original mod_jk, 1.1 in tomcat cvs, and 1.2 in jakarta-tomcat-connectors cvs works with all major webservers (Apache 1.3/2.0, IIS, = NES/iPlanet/Domino) So using jk instead of warp depend on webserver you want to have it. If need today, or tomorrow IIS/NES/DOMINO, use mod_jk, if you only need to use Apache 1.3/2.0 and have APR ready, you can use also = mod_warp. Using mod_warp implies also you have tomcat 4.x as servlet engine, = whereas mod_jk via ajp13 support tomcat 3.2, 3.3, 4.x. If you have today TC = 3.2/3.3 and plan to upgrade at a later time to tomcat 4.x, mod_jk is the = preferred choice. Another point is load-balancing/fault-tolerance. If you want to built = tomcat farms behind your web server, mod_jk is the good choice, mod_warp didn't = support that feature today. >I don't like either - the only reason I use ajp13 is=20 >backward compatibility and the fact that all versions of=20 >tomcat supports it.=20 yep >Ok, the history is a bit complicated, it started with >ajp11 and ajp12 ( first text based, second binary ). >Ajp12 evolved into ajp13 - using same encoding but with some >extensions ( to deal with persistent connections ). > >Looking back - and forward - I think using CDR or XDR would >have been ( or will be ) much better choices for marshalling,=20 >and a subset of RPC or IIOP for protocol. Jk2 supports multiple=20 >protocols, and one of the reasons is to allow a future=20 >migration to a more standard protocol.=20 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=20 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. ;) >We're not the only one inventing protocols - look at DCOP :-) >And it seems full IIOP ( or at least using an existing ORB ) does=20 >have performance impact, or did for KDE people.=20 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. The current marshalling/unmarshalling is really similar to what XDR provide (data type are : smallint (16bits), int (32ints), strings, raw datas (opaque data in XDR), boolean), enums like headers type are present as smallint). Maybe we could add=20 small strings =E0 la MacOs/Pascal ( strings of less than 256 chars), having there first byte indicating length) and also add hyperint (64bits). =20 But one thing I'd like to see in future ajp, is the unmarshalling of headers, ie separate reply headers datas from reply datas.=20 It will help in web-server side to works on such headers, determine and alter some of them.=20 >Plus=20 >it would not easily allow the kind of transports we are using >or want to use ( unix sockets, JNI, doors, etc ).=20 yes >However using a minimal subset ( we only deal with strings, >ints, arrays of string and very simple method calls ) would >eliminate most of the confusion and maybe even provide more >interoperability. Anyway - ajp13 is here to stay - but=20 >I hope it'll be the last binary protocol we invent for >jk. ajp13 is perfect for the current works, ie forwarding request/replies=20 (just need to add some headers packets separated from data packets).=20 It's fast, but need to be extended (that's the ajp14 goal), to allow authentification, configuration informations and better error=20 handling between web-server and tomcat servers. May be we could/should add doc on ajp13 format like the one in XDR (RFC 1832) : ---- 1. AJP13 DATA TYPES Each of the sections that follow describes a data type defined in=20 AJP13, shows how it is declared in the language, and includes a graphic illustration of its encoding. For each data type in the language we show a general paradigm declaration. Note that angle brackets (< and >) denote variablelength sequences of data and square brackets ([ and ]) denote fixed-length sequences of data. "n", "m" and "r" denote integers. For the full language specification and more formal definitions of terms such as "identifier" and "declaration", refer to section 2: "The AJP13 Language Specification". For some data types, more specific examples are included. A more extensive example of a data description is in section 3: "An Example of an AJP13 Data Description". 1.1 Byte and Unsigned Byte We defines 8-bit (1-byte) numbers called byte and unsigned byte. =20 Ranges are [-128,127] for Byte and [0,255] for Unsigned Byte. They are represented in two's complement notation. =20 Their declarations: byte identifier; unsigned byte identifier +-------+ |byte 0 | =09 +-------+ <-8 bits> BYTE UNSIGNED BYTE 1.2 Short Integer and Unsigned Short Integer We also defines 16-bit (2-byte) numbers called short integer and unsigned short integer. Their representations are the obvious extensions of byte and unsigned byte defined above. Ranges are [-32768,32767] for Short Integer and [0,65535] for Unsigned Integer. They are represented in two's complement notation. The most and least significant bytes are 0 and 2, respectively. Their declarations: short identifier; unsigned short identifier; (MSB) (LSB) +-------+-------+ |byte 0 |byte 1 | =09 +-------+-------+ <----16 bits----> SHORT INTEGER SHORT UNSIGNED INTEGER 1.3 Long Integer and Unsigned Long Integer We also defines 32-bit (4-byte) numbers called long=20 integer and unsigned long integer. Their representations are the obvious extensions of short integer and unsigned short integer=20 defined above. Ranges are [-2147483648,2147483647] for Long Integer and [0,4294967295] for Unsigned Long Integer. They are represented in two's complement notation. The most and least significant bytes are 0 and 3, respectively. Their declarations: long identifier; unsigned long identifier; (MSB) (LSB) +-------+-------+-------+-------+ |byte 0 |byte 1 |byte 2 |byte 3 |=09 +-------+-------+-------+-------+ <------------32 bits------------> LONG INTEGER LONG UNSIGNED INTEGER 1.4 Hyper Integer and Unsigned Hyper Integer The standard also defines 64-bit (8-byte) numbers called hyper integer and unsigned hyper integer. Their representations are the obvious extensions of integer and unsigned integer defined above. They are represented in two's complement notation. The most and least significant bytes are 0 and 7, respectively. Their declarations: hyper identifier; unsigned hyper identifier; (MSB) (LSB) +-------+-------+-------+-------+-------+-------+-------+-------+ |byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 | +-------+-------+-------+-------+-------+-------+-------+-------+ <----------------------------64 bits----------------------------> HYPER INTEGER UNSIGNED HYPER INTEGER 1.5 Enumeration Enumerations have the same representation as short signed integers. Enumerations are handy for describing subsets of the integers. Enumerated data is declared as follows: enum { name-identifier =3D constant, ... } identifier; For example, the three colors red, yellow, and blue could be described by an enumerated type: enum { SC_A_CONTEXT=3D 1, SC_A_SERVLET_PATH=3D 2, = SC_A_REMOTE_USER =3D 3 } reqattrs; It is an error to encode as an enum any other integer than those that have been given assignments in the enum declaration. 1.6 Boolean A boolean is a 8-bit datum that encodes the TRUE FALSE with the=20 0x01 (TRUE), 0x00 (0x00) values =20 boolean identifier; +-------+ |byte 0 | BOOLEAN +-------+ <-8 bits> 1.7 Variable-length Opaque Data The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence. Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). Variable-length opaque data is declared in the following way: opaque identifier; or opaque identifier<>; The constant m denotes an upper bound of the number of bytes that the sequence may contain. If m is not specified, as in the second declaration, it is assumed to be (2**32) - 1, the maximum length. The constant m would normally be found in a protocol specification. For example, a filing protocol may state that the maximum data transfer size is 8192 bytes, as follows: opaque filedata<8192>; 0 1 2 3 4 5 ... +-----+-----+-----+-----+-----+-----+...+-----+ | length n |byte0|byte1|...| n-1 | +-----+-----+-----+-----+-----+-----+...+-----+ |<-------4 bytes------->|<------n bytes------>| VARIABLE-LENGTH OPAQUE It is an error to encode a length greater than the maximum described in the specification. 1.8 String We defines a string of n (numbered 0 through n-1) ASCII bytes to be the number n encoded as an unsigned short integer (as = described above), and followed by the n bytes of the string and ending with a = trailing 0 (zero) as for C Strings.=20 Byte m of the string always precedes byte m+1 of the string, and byte = 0 of the string always follows the string's length. Counted byte strings are = declared as follows: string object; or string object<>; The constant m denotes an upper bound of the number of bytes that a string may contain. If m is not specified, as in the second declaration, it is assumed to be (2**16) - 1, the maximum length. The constant m would normally be found in a protocol specification. For example, a filing protocol may state that a file name can be no longer than 255 bytes, as follows: string filename<255>; 0 1 2 3 4 5 ... +-----+-----+-----+-----+-----+-----+...+-----+-----+ | length n |byte0|byte1| ...| n-1 | 0 | +-----+-----+-----+-----+-----+-----+...+-----+-----+ |<-2 bytes-->|<-------------n bytes + 1-------------> STRING It is an error to encode a length greater than the maximum described in the specification. -- To unsubscribe, e-mail: For additional commands, e-mail: