Tuomas Kiviaho created HTTPASYNC-142:
----------------------------------------
Summary: Allow buffer flushing even when output is suspended
Key: HTTPASYNC-142
URL: https://issues.apache.org/jira/browse/HTTPASYNC-142
Project: HttpComponents HttpAsyncClient
Issue Type: Improvement
Affects Versions: 4.1.3
Reporter: Tuomas Kiviaho
{{DefaultNHttpClientConnection}} flushes output buffer to the channel at
{{produceOutput}}.
{code}
if (this.contentEncoder != null) {
handler.outputReady(this, this.contentEncoder);
if (this.contentEncoder.isCompleted()) {
resetOutput();
}
}
}
if (this.outbuf.hasData()) {
final int bytesWritten =
this.outbuf.flush(this.session.channel());
if (bytesWritten > 0) {
this.outTransportMetrics.incrementBytesTransferred(bytesWritten);
}
}
{code}
If the buffer is only partially flushed and the handler has suspended the
output then the remaining bytes are written to the channel only when output is
requested again. This would lead to unnecessarily trip though the handler.
Before looking at the code I imagined that the {{IOControl}} is aimed to
control whether to encode/decode the content, but it's just basically a shim of
connection and therefore handlers control directly the channel read/write. This
isn't exactly a problem with the input side although one might to have finer
control over whether of not to try to filling of the input buffer, but on the
output side I need to postpone the suspension until the buffer is flushed
completely and this adds additional glue and roundtrip to the handler.
It would feel more natural to me to have {{IOControl}} also on top of
{{IOSession}} and here the suspension would respect the state of the buffers.
This would be the control that is given to the handler instead of the direct
one that is basically the connection itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
