RE: PROPOSAL: clientFlush() method

[GOMEZ Henri <hg...@slib.fr>]

+1, it should reduce greatly overhead and let the 
OS stack handle the traffic directly, it will also
certainly reduce overhead in reader part (ie web server).

-
Henri Gomez                 ___[_]____
EMAIL : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-----Original Message-----
>From: costinm@covalent.net [mailto:costinm@covalent.net]
>Sent: Thursday, May 30, 2002 7:55 PM
>To: List Tomcat-Dev
>Subject: PROPOSAL: clientFlush() method
>
>
>Hi,
>
>I would like to add a new method to Response. 
>
>clientFlush() will be called by ServletOutputStream.flush() to 
>notify the
>container ( and the low level connector ) that the user has 
>explicitely 
>asked for the stream to be flushed. 
>
>The default impl. will be empty, and in coyote adapter we'll generate
>an Action.CLIENT_FLUSH that may be interpreted by the connector.
>
>This would allow the connector to increase the granularity, which in 
>turns result in about 20% reduction in the overhead ( for ajp/socket ).
>
>This happens by allowing the use of a BufferedOutputStream on the
>socket - the packets to send the header and the first chunk and
>the end response messages will all be sent at once, in one 
>write() operation instead of 3. 
>
>The servlet spec allows us to do that, but we must honor the flush()
>requests.
>
>I'll leave the option as disabled in jk2 ( since 4.1 and the current
>3.3 doesn't support this ), but an option will enable the buffered 
>writing.
>
>Comments ? Larry, Bill ? 
>
>( I tested this with 3.3 - Remy, I suppose something similar 
>will be done
>in a future release of 4.1.x, I don't want to delay the release )
>
>Costin
>
>
>--
>To unsubscribe, e-mail:   
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>