Some feedback:
- thank you very much for this documentation !
- +1 on making this documentation the "official" ajp13 spec, fixing it and
fixing mod_jk to match the spec :-)
- the java code is based on an earlier experimental protocol, and had as
goals to abstract the communication protocol ( i.e. support ajp12, ajp13,
jni, future versions of the protocol). We learned that it's hard, makes
code too complex and doesn't provide real benefits - it's much better to
use a collection of shared tools/utils.
- goals: support pools of servlet containers
- connections are assigned from a pool of existing connections, and go
to possibly different containers ( if load balancing is used )
- jvm_route - if mod_jk is doing load balancing, it will send the "id" of
the tomcat instance to tomcat. Tomcat will include the "id" in the session
id cookie, and all requests in the same session will be forwarded to the
same tomcat. ( without this it is very hard to make sure that requests in
the same session go to the same server )
- the reason for not sending the full request body, but only the first
chunk and using a callback to get more - it is possible that some requests
will not use the body, or will use it at a latter stage. It also improve
support for uploading big files ( where sending the full body will use
too much heap on the java side ). Another reason - TCP will split the
packet anyway, and it would be good to use a size that makes the tcp
transfer efficient.
- limiting the packet size - it reduces the memory needs for Java side, it
was hoped to be more efficient.
- endian-ness - Java representation of integers was used ( happen to be
the same as XDR ). I don't think there is any magic in sys/socket - it
should be code to insure the right encoding in mod_jk.
- +1 on adding a packet type for the request.
- context/servlet_path - it is a feature that never got implemented,
mostly because of differences between the way a web server parse a request
and the servlet spec.
- authentication - it's a very important feature to implement.
- support for requests > 8k are also a big priority.
- I think it's a good idea to send multiple packets for the body and also
for big requests - that would allow the java side to use fixed buffers.
Costin
