[
https://issues.apache.org/jira/browse/HTTPASYNC-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho closed HTTPASYNC-142.
------------------------------------
This will do then.
I was tempted to check out the beta and at first glance the API looks pleasing.
AsyncDataConsumer/Producer will still support somehow back-pressure via
{{updateCapacity}} and {{availability}} like Servlet3 does via
Read/WriteListener. It's nice to see that buffers are directly accessible and I
assume that they are pooled so that they are valid only inside the {{consume}}
method but a hypothetical bridge between Http Async 4.x APIs would not need to
do a buffer copy even when the buffer isn't consumed entirely at one go since
it would basically get the same buffer over and over again until it's fully
consumed. I hope also that the server implementation allows response to be
sent before request is fully consumed. I had to manually craft a
{{PipelineEntry}} in 4.x to allow this.
>From documentation point it would be quite pleasing to see a bridge to the 4.x
>Async APIs because this would clarify such things that I mentioned above
>better than just upgrading the already existing one. This particular problem
>that I had would be solved with indeed with a bridge. Now I had to do a cast
>from {{IOControl}} to {{SessionBufferStatus}} to be able to ensure that
>everything is flushed before actually suspending content producing.
> 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]
