Fix high CPU utilization regression on event streaming #3318
Conversation
| @@ -357,6 +357,14 @@ HttpResponseOutcome AWSClient::AttemptExhaustively(const Aws::Http::URI& uri, | |||
| { | |||
| break; | |||
| } | |||
| if (request.IsEventStreamRequest() && | |||
There was a problem hiding this comment.
Can we also extend this change to the smithy client else pending fixes will pile up
There was a problem hiding this comment.
I'd prefer to have a completely different design of streaming for the smithy client.
also smithy client does not use for loop for retry logic.
| @@ -15,10 +15,11 @@ namespace Aws | |||
| namespace Stream | |||
| { | |||
| const char TAG[] = "ConcurrentStreamBuf"; | |||
|
|
|||
| const int ConcurrentStreamBuf::noData = ((((('n' << 8) | 'z') << 8) | 'm') << 8) | 'a'; | |||
There was a problem hiding this comment.
Where is 'n' and 'm' evaluated ? I see that 'z' and 'a' states are treated now as same state when try lock can't be achieved or m_getArea is empty
There was a problem hiding this comment.
ConcurrentStreamBuf::noData is a magic variable with a value of 1634564718
1634564718 represents an integer where the bytes are 'a', 'm', 'z', and 'n'. Just a bit of fun. I thought about also using leetspeak, but decided to use something that we can claim as a reserved variable/keyword.
As mentioned on the comment, it is a
A flag returned by underflow() if there is no data available at the moment but stream must not be closed yet.
We can't return -1 - it is already reserved for eof.
We can't return single byte - it will be treated as a valid user value from the stream.
But we still can return some int.
Honestly, it is still kind of an "implementation defined hack", but it works.
SergeyRyabinin
deleted the
sr/transcribe_fix_last_final_fix_final_v2b
branch
Issue #, if available:
introduced by #3302
The CPU utilization got back to 100% for a streaming because of input stream polling
Description of changes:
Introduce another stream special value
intreturned by peak, with a value ofamzn, to represent the condition when: we have nothing to send AND session is still open.Regular EOF aka -1 will also always close the stream. 'a' and 'z' are also invalid values because they can also represent a valid byte from the stream.
tested by running streaming session and observing
htopCheck all that applies:
Check which platforms you have built SDK on to verify the correctness of this PR.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.