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 Thu, 27 Feb 2003 17:45:49 GMT
>>>> read-error should not happen, as mod_jk could send a quit-paket or 
>>>> something (analog to the ftp-protocol)
>>> read-error happen BECAUSE APACHE HTTPD server close client
>>> when it recycle them.
>> i hoped, you would react on this one.
> What's the problem with this connection closing handling ?
> tomcat detect a closed connection, and close its own
> socket side then free the thread.

i guess server-admins want to distinguish between normal-server 
operation and network-errors.

currently the log is flooded with unimportant log-messages that are the 
result of bad error-detection (i hope, i can do better)

>> i'm not very much into apache httpd's internals, but i guess, that a 
>> child isn't just killed, but notified to terminate itself (OK, perhaps 
>> a kill-signal is used), but the question is, if mod_jk is called when 
>> a child exits/gets killed. if mod_jk can catch this case, it should 
>> gracefully close the connection (like quit-command in FTP-protocol), 
>> so tomcat knows, that everything is OK.
> As I said previously, Apache kill childs under heavy load, and you
> want add extra delays by sending a message to warn tomcat that
> the connection will be closed ?

I'm not talking about a warning.
I'm talking about a "close the connection"-command which mod_jk is 
sending to tomcat. that's the "perfect" sollution. Tomcat can blindly 
close the connection, and if the connection was closed without such 
command, we would have some kind of error-situation.

> Another point is that adding new message to protocol make
> it incompatible with olders java implementations or with alternate
> implementations (like jetty).

OK, but is there a handshake when mod_jk connects to tomcat?
mod_jk could receive a sub-version of the protocol to determine which 
extensions are available.

> That was one of the reason why I started to think about an ajp13++
> or ajp14.

I hope that ajp14 will do better.
I would also use JNI-workers, if mod_jk2 would be stable enough. I read 
that it didn't enjoy such extensive tests as mod_jk. Is this still true?
Still i'm worriing about apache-stability when using JNI-workers.

>> i know, that apache kills and spawns new child every now and than, but 
>> as this is normal, this should be handled more gracefully.
>> i cannot supply you with a patch, because i'm not that good in writing 
>> apache-modules (in fact, i never did that before, and i didn't write 
>> any C/C++ for some years now)
> I don't see, for now, much need for Tomcat to know that the connection
> has been dropped gracefully or abnormally, since it will make us :
> - update the protocol paper (easy)
> - update java side implementations (easy for JTC, dunno for Jetty,
>   may be impossible for Tomcat 3.2.x).

Some protocols include version-numbers in their handshake, to overcome 
such problems. I agree with you, that the protocol should be some kind 
of KISS (keep it simply stupid)

> - add native side code to trap child/thread handle the shutdown
>   more gracefully.

that would be a much more "cleaner" sollution.

> Updating the protocol may create problems with old implementations
> and as such will great unnecessary questions/problems reports
> from users...

only, if future extensions were not part of the protocol-design
(for example via version-numbers). i guess this is the case.

> I'd rather like to see such energy invested in jk2 and ajp13 extensions.

i would look forward to use JNI-workers, if somebody would tell me, how 
stable this is.

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

View raw message