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?
--
Alexander Schwartz ([EMAIL PROTECTED])
http://www.ahus1.de
--- jk_ajp_common.c.old Fri Jan 23 16:26:12 2004
+++ jk_ajp_common.c Fri Jan 23 16:28:02 2004
@@ -963,10 +963,16 @@
* or Tomcat crashed. In any case we cannot recover this.
*/
+ // as+gj/20040123: we don't want to try the buggy POST recovery as it
+ // seems to repost buggy data
+ // BUT: doesn't work!
+ // op->recoverable = JK_FALSE;
+
jk_log(l, JK_LOG_DEBUG,
"ajp_send_request 2: "
- "request body to send %d - request body to resend %d\n",
- ae->left_bytes_to_send, jk_b_get_len(op->reply) - AJP_HEADER_LEN);
+ "request body to send %d - request body to resend %d/%d\n",
+ ae->left_bytes_to_send, jk_b_get_len(op->reply) - AJP_HEADER_LEN,
+ jk_b_get_len(op->post) - AJP_HEADER_LEN);
/*
* POST recovery job is done here.
@@ -977,10 +983,18 @@
* remote Tomcat
*/
if (jk_b_get_len(op->post) > AJP_HEADER_LEN) {
- if(!ajp_connection_tcp_send_message(ae, op->post, l)) {
- jk_log(l, JK_LOG_ERROR, "Error resending request body\n");
- return JK_FALSE;
- }
+ // as+gj/20040123: seems to be buggy, doesn't fit the debug output
+ // above, customers complain about seeing wrong user's data when doing
+ // a login-POST
+ // if(!ajp_connection_tcp_send_message(ae, op->post, l)) {
+ // jk_log(l, JK_LOG_ERROR, "Error resending request body\n");
+ // return JK_FALSE;
+ // }
+
+ // as+gj/20040123 recovery is disabled above shoudn't happen!
+ jk_log(l, JK_LOG_ERROR, "Shouldn't be here resending request body! (as+gj/20040123)\n");
+ op->recoverable = JK_FALSE;
+ return JK_FALSE;
}
else {
/* We never sent any POST data and we check if we have to send at
@@ -1009,6 +1023,8 @@
s->content_read = len;
if (!ajp_connection_tcp_send_message(ae, op->post, l)) {
jk_log(l, JK_LOG_ERROR, "Error sending request body\n");
+ // as+gj/20040123
+ op->recoverable = JK_FALSE;
return JK_FALSE;
}
}
@@ -1279,6 +1295,9 @@
* receiving upload data and we must consider that
* operation is no more recoverable
*/
+ // as+gj/20040123:
+ // don't want to recover
+ op->recoverable = JK_FALSE;
if (! op->recoverable) {
*is_recoverable_error = JK_FALSE;
jk_log(l, JK_LOG_ERROR,
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
