tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Köhler <>
Subject Re: socket errors in catalina.out and mod_jk.log
Date Sat, 01 Mar 2003 00:15:14 GMT
>>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. 

yes, but how? how can either client or server guess, which extensions 
the other side supports?

>>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 ? 

such are not part of ajp13, and adding them will surely brake 
compatibility to existing implementations as long as i can't determinte 
the supported features of the other side.

> 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 ).

same reason as above

>>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.

Henri was protesting. I'm just repeating the Henri's doubts.

>>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.

yes, but what will the other side do if it receives an unsupported 
package? it might drop a note to the log, and that would result in a 
log-flood again :-(

>>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 ? 

You forget, that HTTP is designed, to be a temporal connection. Without 
keep-alive and such (which were added to HTTP1.0), a HTTP connection 
doesn't survive longer than one request.
Sending headers and receiving them could also be interpreted, as a 

A connection between apache and tomcat should survive a longer time, and 
delivers many requests.

> Does anything in the current jk prevent you from adding any kind of
> handshake you need ?  

umm ... yes?
Adding new messages is a bad bad thing. I agree with Henri's opinion in 
this case. It's just a shame, that the protocol isn't designed to be 
extended without loosing compatibility.

> 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.

So you really think, that many administrator cares about the 
documentation, or if they do understand it? You will have people mailing 
to the list, or just leaving the options "as is", so mod_jk wouldn't 
take advantage of the features with default configuration.

>>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.

So where can i find the "final" draft or something, that explains all 
that stuff?
After all you wrote, this draft should include a statement like 
"additional message-type that can be added, and should be silently 
ignored", so every conformant implementaion reacts the same way.

> 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. 

hmm ...
- HTTP includes a version in each request and each response
- a client does not know which features the server supports
- => it blindly sends a request with a "let's see what happens" strategy
- ...

this should not apply for AJP13
- the versions or feature information could be exchange at the start of 
the connection, a connection should remain for some amount of time
- a client should know, if the server supports idle-message or 
quit-messages, the server should also know, which message the client may 
understand (for future enhancements and full compatibility)

> 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.

why should it get "unstable". how can a protocol get unstable?
the protocol isself should be simple, and an implementaion shouldn't get 
to complicated (if we have to much additions, or even conflicting 
additions, it's time for a new protocol)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message