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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
