[
https://issues.apache.org/jira/browse/HTTPASYNC-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPASYNC-142.
-----------------------------------------
Resolution: Won't Fix
[~tuomas_kiviaho] Your analysis is correct and your point is perfectly valid.
The non-blocking i/o layer in HC 4.0 has been designed with an assumption of
message exchange handlers having a complete and unrestricted access to the
underlying HTTP connection. That assumption was valid in the context HTTP/1.1
but had to be revised in HC 5.0 given that a single HTTP/1.1 or HTTP/2 could be
serving multiple pipelined or multiplexed message exchanges. As a result HC 5.0
has a completely different message transport APIs and no longer has this issue.
I am very tempted to leave things as-is in HC 4.x and work on improvements in
HC 5.0. If you are willing to work on fixing this issue in HC 4.0 please do
feel free to re-open this ticket.
Oleg
> 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
> Priority: Major
>
> {{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]
