Am Di, den 10.02.2004 schrieb Henri Gomez um 15:52:
To fix this serious bug we should modify the current service API.
We should store the POSTED datas in the jk_ws_service_t area and not in ajp_operation_t, as such the first worker will feed the POST datas in an area which will be available to the second one.
Aternate idea are of course more than welcome;
As I understand it mod_jk is "stable", almost "deprecated", and mod_jk2
is "the future". Therefore I suggest:
* no API change in mod_jk
* mark the operation as unrecoverable when an error occurs after
the headers have been sent to the tomcat, that is only fixing
bugs and trying not to do big changes * concentrate your efforts on mod_jk2 and give people a reason to upgrade :)
Marking the operation as unrecoverable might also solve the other
(lb-)problem: when you shut down the first tomcat after it has already
sent some data to the client mod_jk forwards the request to the second
tomcat and appends the response of the second tomcat to the response of
the first tomcat. I'll deliver a sample jk.log soon.
I have prepared a patch for 1.2.4/1.2.5, and I am happy to port it to HEAD -- if someone checks that it leaves no loose ends.
Thanks for taking this serious.
Alex.
PS: this "empty POST" bug is not the explanation for the session mixup (yet)? Any ideas on that one?
Well I'm sure we could update the API to have this problem fixed.
The post buffer used for recovery should be create in service and passed to the differents workers, making the POST recovery working for ajp and lb workers.
If nobody have objections I'll take a look at this since I don't like the idea of having something working for only HALF of HTTP protocol.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
