Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
To: tomcat-dev@jakarta.apache.org
From: Costin Manolache <cmanolache@yahoo.com>
Subject: Re: socket errors in catalina.out and mod_jk.log
Date: Fri, 28 Feb 2003 13:09:34 -0800
Lines: 88
Message-ID: <b3oj8k$ul3$1@main.gmane.org>
References: <b3gg84$sgb$1@main.gmane.org> <3E5C9554.70109@apache.org>
 <b3j0hn$poc$1@main.gmane.org> <3E5DF2BB.3030502@apache.org>
 <b3l9if$99i$1@main.gmane.org> <3E5E3464.8050302@apache.org>
 <3E5E8788.8010601@mail.more.net> <b3m2qp$744$1@main.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8Bit
User-Agent: KNode/0.7.2
Sender: news <news@main.gmane.org>

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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org