Hi Lary,
Larry Reisler wrote:
Thanks for your reply. There is a holiday here right now, so I'm not
sure if I will be able to get to file the Bugzilla issue before the
holiday break.
Maybe this time we are faster than our request ticketing ...
We tried a few different versions of mod_jk (the early ones had other
issues), but all the latest ones showed the problem. We are
currently using mod_jk 1.2.25.
In desperation, I was able to create a patch to mod_jk that seems to
prevent the symptom from occurring. Here is the diff for the file
jk_ajp_common.c: 1742,1751d1741
< // Removing extra flush buffer if we do not need it.
< if (headeratclient == JK_FALSE) {
< int code = (int)jk_b_pget_byte(op->reply,0);
< unsigned int len = (unsigned int)jk_b_pget_int(op->reply,1);
< if ((code == JK_AJP13_SEND_BODY_CHUNK) && (len == 0)) {
< jk_log(l, JK_LOG_DEBUG, "Received flushbuffer -- ignoring");
< continue;
< }
< }
<
I'm a little reluctant to use your approach. It should work, but the
peeking for the message code and length does not belong into the get
reply function. The best place for the patch would be in the callback
handling, but there we don't know, if we already received the headers.
So either we pass some additional info to the callback handling (status
info about the request processing stage), or we prevent the flushing
later. I decided to move an already existing flag "response_started"
from the web server private data to the public service struct and use
it inside the callback handler.
This patch was committted
(http://svn.apache.org/viewvc?view=rev&revision=579349). You can find a
simple download form of it under
http://people.apache.org/~rjung/mod_jk-dev/patches/flush-before-header.patch
The patch looks lengthy, but in fact did only small changes.
It would be helpful, if you could try it with your reproduction scenario.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
