[
https://issues.apache.org/jira/browse/TS-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338806#comment-14338806
]
Brian Geffon commented on TS-3413:
----------------------------------
[~shinrich] your patch makes sense to me.
However I do have an issue with the following check:
{code}
if (stream->is_body_done() && payload_length < send_size) {
flags |= HTTP2_FLAGS_DATA_END_STREAM;
}
{code}
This seems flawed, I think what we really should be checking is that
{{stream->is_body_done() && all_sent_bytes_were_received)}} Because you can
receive a {{TS_FETCH_EVENT_EXT_BODY_DONE}} as soon as all bytes have been
received from the client forcing it to mark the body as done. And if suppose
your read buffer is full requiring two reads you'll mark the stream as complete
too early. Does this seem like a reasonable concern [~rokubo]? Basically what
I'm getting at is that the decision to end the stream needs to be based not
only on a single read event, instead on all of the read events. Makes sense?
> High CPU utilization when processing Http/2 traffic
> ---------------------------------------------------
>
> Key: TS-3413
> URL: https://issues.apache.org/jira/browse/TS-3413
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2, Performance
> Reporter: Susan Hinrichs
> Assignee: Susan Hinrichs
> Fix For: 5.3.0
>
> Attachments: ts-3413.diff
>
>
> Running ATS in forward transparent mode with Http/2 support enabled. After a
> few page views, ATS gets into a state where it is consistently using more
> than 100% CPU. I think what is happening is that the origin server is closing
> the connection (we get a TS_EVENT_VCONN_EOS in FetchSM). FetchSM sends a
> BODY_DONE to Http2ClientSession but the http_vc (origin socket?) is never
> closed, so with each poll interval the EOS is reported again and again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
