[
https://issues.apache.org/jira/browse/HTTPCORE-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16772323#comment-16772323
]
Richard Hernandez commented on HTTPCORE-568:
--------------------------------------------
[~olegk] I submitted a [pull
request|https://github.com/apache/httpcomponents-core/pull/110].
There's another minor race condition in AbstractHttp1StreamDuplexer that I'll
try to fix soon.
> ReactiveDataConsumer receives at most 65k bytes over HTTP/1.1
> -------------------------------------------------------------
>
> Key: HTTPCORE-568
> URL: https://issues.apache.org/jira/browse/HTTPCORE-568
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore
> Affects Versions: 5.0-beta6
> Reporter: Richard Hernandez
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [The addition of an input window to
> AbstractHttp1StreamDuplexer|https://github.com/apache/httpcomponents-core/commit/3252c39fd803f86c6856caa83b683d31e45b8391#diff-4ceed36abd5cb9433de24f108c90195aR292]
> causes ReactiveDataConsumer to only receive as many bytes as the input
> window's initial size. By default, this is only 65,536 bytes.
> The problem is that updateCapacity is only called after the window is
> exhausted. This happens after consume returns, which is where
> RectiveDataConsumer tries to signal available capacity to its
> capacityChannel. As a result, it's never able to signal more capacity to
> AbstractHttp1StreamDuplexer, and all future bytes on this channel get stuck
> in the system's socket receive buffer.
> As far as I can tell, the capacity channel was never set in prior releases.
> It just happened to work because my tests never exhausted the buffer space in
> ReactiveDataConsumer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
