Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

logReadCloser: ensure EOF after Close() #3034

Merged
merged 2 commits into from
Jan 19, 2018
Merged

Conversation

rbruggem
Copy link
Contributor

logReadCloser would spin on Read after Close because EOF was not returned.
This change ensures EOF is returned once Close() is called.

Fixes #3033.

@rbruggem rbruggem requested a review from rndstr January 19, 2018 10:48
@@ -99,7 +99,8 @@ func (l *logReadCloser) Read(p []byte) (int, error) {
}

func (l *logReadCloser) Close() error {
for _, rc := range l.readClosers {
for i, rc := range l.readClosers {
l.eof[i] = true

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

@rade
Copy link
Member

rade commented Jan 19, 2018

There's another issue: when readInput encounters a non-eof error, it just terminates. This can cause Read to get stuck since it will think there are still active readers.

@rbruggem rbruggem force-pushed the very-high-cpu-on-get-logs branch 2 times, most recently from cbc533f to 8b363b8 Compare January 19, 2018 13:45
Roberto Bruggemann added 2 commits January 19, 2018 14:13
This change makes the underlying reader set their corresponding `eof` slot to true on termination.
This make the overall logReadCloser converge to EOF in case of errors of the underlying readers, therefore prevent spinning on read.

`bufio.Reader.ReadBytes` may not return io.EOF when `Close()` closes the underlying reader.
For instance, closing logReadCloser from the Scope App makes `bufio.Reader.ReadBytes` produce the following error: `http2: response body closed`.
Adding the !EOF check to the loop condition ensures not reading from closed channels.
@rbruggem rbruggem force-pushed the very-high-cpu-on-get-logs branch from 8b363b8 to 9198f6b Compare January 19, 2018 14:29
@rbruggem rbruggem merged commit ea0b549 into master Jan 19, 2018
@rbruggem rbruggem deleted the very-high-cpu-on-get-logs branch January 19, 2018 15:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants