Sven Köhler wrote: >> There is another problem with how mod_jk handles the ajp connetor >> sockets. That is the one to one mapping of apache child process to an ajp >> connector. On an apache server that serves normal http requests you can >> end up with many idle socket connections to Tomcat, and Tomcat will spawn >> many more Connector threads than it needs to handle the request volume. > Changing this, is much work, and it might get better with Apache 2.0 as > it uses Threads.
I don't know any way to avoid this for apache1.3 - if we close the connections the performance will drop. The next request can come on any of the apache childs. > I took a short look at the ajp13 protocol draft, and the design of the > protocol is really simple, too simple. There are few knwon problems with the protocol - both sides of jk2 are designed to support multiple protocols and extensions. > I can't see any possibility to send idle-packets to prevent a connection > from timing out. That's a basic requirement, but it seems, that nobody > thought of it. It also doens't include a "quit-command" (quits the What prevents you from sending idle packets ? Or adding a quit command ? You can implement both - either with new packet types or by using normal Ajp requests with some special URIs ( that will be handled by a jk handler or even by a servlet ). > connection), but a "shutdown"-command (shuts down the servlet container, > i think it's unused at the moment). Again - both can be easily added, if anyone has an itch. > so tomcat's connections will keep timing out, and i see no sollution for > this with the current protocl design. The protocol is a simple request/response - with apache initiating the communication, and some twists to avoid some roundtrips. You can send any type of packet - and do any kind of action. The only change to the protocol that I think we should do is to replace the marshalling with XDR. Besides that - we can add as many packets and messages as we want - it's just RPC. > I cannot find a describtion of some kind of simple handshake in the > draft i've found. so mod_jk is totally unaware of the server it's > talking too. Is there any handshake in the HTTP protocol ? Does anything in the current jk prevent you from adding any kind of handshake you need ? There is one proposal ( made by Henri ) - that include capabilities and version checking. I personally don't see the real need - in most cases it is much easier to just configure this explicitely. > I think, AJP needs a better design than AJP13. > all i found about AJP14 shows, that it comes with more features, but > doesn't give a damn on the basic-problems. Again - ajp13 defines a marshalling protocol and the 3-4 messages that are needed for request processing. It is not an exclusive list - other messages can be added. In many cases simpler is better - HTTP is a very good proof of that. I don't see any good reason to make the ajp13 protocol any more complex than it is. I am perfectly fine with adding other message types via plugins ( Jk handlers and mod_jk components ), but the simple and stable base protocol needs to remain stable. Costin > But AJP was flamed enough now! If we have enough ideas, we could write > our own connector for Tomcat and a module for Apache HTTPD. > Any volunteers ? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
