tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: socket errors in catalina.out and mod_jk.log
Date Fri, 28 Feb 2003 21:09:34 GMT
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.

> 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:
For additional commands, e-mail:

View raw message