[
https://issues.apache.org/jira/browse/HTTPCORE-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636231#comment-17636231
]
Oleg Kalnichevski commented on HTTPCORE-730:
--------------------------------------------
> I noticed that the removed block in the fix had been added as a bug fix in
> late 2020
[~sajiniekavindya] I am aware of that. The change-set you are referring to has
multiple changes. One was likely a mistake. Truth to be told, the 4.x code line
is no longer getting the same degree of integration testing as the 5.x.
Having said that, please do help us test the latest 4.x snapshot and let me
know if everything works as expected. If I do not hear from you within a week
or so I will presume everything is OK and proceed with a release from the 4.4.x
branch.
Oleg
> High CPU Utilization if data is not read from SharedInputBuffer when the
> internal buffer is completely full
> -----------------------------------------------------------------------------------------------------------
>
> Key: HTTPCORE-730
> URL: https://issues.apache.org/jira/browse/HTTPCORE-730
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.4.16
> Reporter: Sajinie Kavindya
> Priority: Major
> Attachments: HttpNIOTest.zip
>
>
> In 4.4.16-SNAPSHOT, when I use SharedInputBuffer class and do not read the
> data from the buffer by calling 'read' methods when the buffer is completely
> full, I experience a high CPU utilization. By looking at the
> 'SharedInputBuffer#consumeContent' method implementation, I can see that the
> input is suspended when the buffer does not have enough space to get data
> transferred from the ContentDecoder. But even after suspending the input, I
> noticed that the event mask associated with the session was still 'read'.
> Furthermore, SharedInputBuffer in 5.x is implemented in a way to adjust the
> capacity of the buffer to ensure it can accommodate the required capacity
> (and no input suspension). Hence, I believe 5.x might not have the above
> behavior. But unfortunately, moving to 5.x is not an option for me at this
> moment.
> So, does 4.x really have a bug here under the above-mentioned conditions? If
> not, could you please explain this behavior?
> ----
> Attaching a sample program, which will exhibit the problem. Please note that
> I have done the following alteration to the BasicAsyncResponseConsumer class.
> * the internal buffer is the type of 'SharedInputBuffer'.
> * MAX_INITIAL_BUFFER_SIZE value is set to 16384 bytes.
> Also,
> * Backend sends a payload larger than MAX_INITIAL_BUFFER_SIZE.
> * SharedInputBuffer#read method is not invoked by any threads purposefully.
> * The latest 4.x branch (4.4.16-SNAPSHOT) is used inside this program.
> You may run the 'Main' class of the program.
> Your input is highly appreciated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
