My solution was also in the routine ap_send_fb_length, but I set up the code
to flush the output buffer every time it extracts data from the input
stream. My reasoning was that the original sender of the data must have
flushed the data through their output stream somehow, otherwise it would
never have arrived in ap_send_fp_length. If the original sender caused a
flush, then this routine has no business delaying the data on it's way. What
I didn't realise was that it was a windows-specific feature, where (if I
remember correctly from the Apache bug solution) ap_bread works differently
from the Unix version. Anyway, I just added the following code immediately
*after* the "while (n && !r->connection->aborted)" loop in
ap_send_fb_length:

  /* RMG Test version 24/8/2000 */
  if (!r->connection->aborted) {
   ap_bflush (r->connection->client);
  }

This would probably produce a slight performance penalty on Unix under some
circumstances. Anyway, I never bothered submitting this as a fix because
somebody had already figured out a better solution. On the other hand, I
still use my private version for myself, because I don't know if the real
bug fix is available yet.

Regards,
Raoul Gough.


----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 27, 2000 10:35 AM
Subject: RE: buffered stream in Apache JServ Protocol (AJPv1.1)


[snip]
> You didn't tell your solution?




--
----------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Archives and Other:  <http://java.apache.org/main/mail.html>
Problems?:           [EMAIL PROTECTED]

Reply via email to