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.

Sign up for GitHub

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

Jump to bottom

[close #2371] Don't report EOFError #2382

Closed
wants to merge 1 commit into from
Closed

[close #2371] Don't report EOFError #2382

wants to merge 1 commit into from

Conversation

schneems
Copy link
Contributor

I think this fixes #2371. But there are some bigger problems:

  • I can comment out these lines and tests still pass for me locally:
      # rescue SystemCallError, IOError, EOFError
      #   raise ConnectionError, "Connection error detected during read"

  • It doesn't look like we're triggering the behavior that would fire the # in the output. We should figure out how to get that into our output while testing, and then assert our fix, fixes it.

  • It looks like the exception catching is extremely nested. From this backtrace:

/Users/rschneeman/Documents/projects/puma/lib/puma/client.rb:154:in `try_to_finish'
/Users/rschneeman/Documents/projects/puma/lib/puma/client.rb:134:in `reset'
/Users/rschneeman/Documents/projects/puma/lib/puma/server.rb:428:in `block in process_client'
/Users/rschneeman/Documents/projects/puma/lib/puma/thread_pool.rb:335:in `with_force_shutdown'
/Users/rschneeman/Documents/projects/puma/lib/puma/server.rb:427:in `process_client'
/Users/rschneeman/Documents/projects/puma/lib/puma/server.rb:260:in `block in run'
/Users/rschneeman/Documents/projects/puma/lib/puma/thread_pool.rb:143:in `block in spawn_thread'

The EOFError would be rescued in both try_to_finish and in reset. Maybe more. It's unclear, from a unit perspective which of these exception catching locations exist for what reason. Basically: Were they just tacked on or is there a valid reason they're there. Being able to delete/comment code and have tests still pass is not confidence-inspiring in this exception case.

TODO

schneems added a commit that referenced this pull request Sep 25, 2020
@schneems
[close #2371] Do not log EOFError
27c78f2 
This is a continuation from #2382.

One of the ways that an EOFError can be triggered is by opening a connection, not writing to it, then closing it (there may be others). This should be an expected and non-exceptional activity. When it happens we should not log it.

This commit gets the test in the prior commit to pass.

The change to client.rb makes sense to me as this is the initial place where we're reading from the socket and then finding out the stream has been closed. Im not quite sure why the code in server.rb is needed. I think this comes from when the server is shutting down and trying to finish out connections.

I don't think this is the 100% right way to do things. I'm guessing that if we get an EOFError on a connection we should somehow consider it "dead" and never try to read from it again. I don't know if there's a better way to signify this in the `try_to_finish` method of client.rb
@schneems schneems mentioned this pull request Sep 25, 2020
Merged
@schneems schneems closed this Sep 25, 2020
schneems added a commit that referenced this pull request Sep 25, 2020
@schneems
[close #2371] Do not log EOFError
dfd198d 
This is a continuation from #2382.

One of the ways that an EOFError can be triggered is by opening a connection, not writing to it, then closing it (there may be others). This should be an expected and non-exceptional activity. When it happens we should not log it.

This commit gets the test in the prior commit to pass.

The change to client.rb makes sense to me as this is the initial place where we're reading from the socket and then finding out the stream has been closed. Im not quite sure why the code in server.rb is needed. I think this comes from when the server is shutting down and trying to finish out connections.

I don't think this is the 100% right way to do things. I'm guessing that if we get an EOFError on a connection we should somehow consider it "dead" and never try to read from it again. I don't know if there's a better way to signify this in the `try_to_finish` method of client.rb
nateberkopec pushed a commit that referenced this pull request Sep 27, 2020
@schneems
[close #2371] Do not log EOFError (#2384)
f282c22 
* Failing test for #2371

The EOF can be triggered by opening a connection, not writing to it, then closing the connection. When this happens we can detect if an error was logged or not by inspecting the stderr string. 

This test fails

* [close #2371] Do not log EOFError

This is a continuation from #2382.

One of the ways that an EOFError can be triggered is by opening a connection, not writing to it, then closing it (there may be others). This should be an expected and non-exceptional activity. When it happens we should not log it.

This commit gets the test in the prior commit to pass.

The change to client.rb makes sense to me as this is the initial place where we're reading from the socket and then finding out the stream has been closed. Im not quite sure why the code in server.rb is needed. I think this comes from when the server is shutting down and trying to finish out connections.

I don't think this is the 100% right way to do things. I'm guessing that if we get an EOFError on a connection we should somehow consider it "dead" and never try to read from it again. I don't know if there's a better way to signify this in the `try_to_finish` method of client.rb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Puma 5.0.0 HTTP connection error: #<Puma::ConnectionError: Connection error detected during read>
1 participant
@schneems