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

When monitoring idle connections, only call eof on tcp socket #912

Merged
merged 2 commits into from
Aug 25, 2022

Conversation

quinnj
Copy link
Member

@quinnj quinnj commented Aug 24, 2022

In a heavy cloud storage workflow, I encountered the following error:

AssertionError: ctx.bytesavailable > 0 || !(ctx.isreadable)

with traces back to calling eof(::SSLContext) from monitor_idle_connection.

As the workflow was highly concurrent, I believe the error was just a data race
between an old async monitor_idle_connection task calling eof -> wait_for_decrypted_data,
but when returning from wait_for_decrypted_data due to a new connection being reused in HTTP.jl,
the handshake was redone, which resulted in the AssertionError shown above.

The proposal here is that when monitoring idle connections, we only call eof on the underlying
TCPSocket, since we're really only concerned with knowing whether the core socket gets additional
data, encrypted or not, when we don't expect it.

In a heavy cloud storage workflow, I encountered the following error:

```
AssertionError: ctx.bytesavailable > 0 || !(ctx.isreadable)
```
with traces back to calling `eof(::SSLContext)` from `monitor_idle_connection`.

As the workflow was highly concurrent, I believe the error was just a data race
between an old async `monitor_idle_connection` task calling `eof` -> `wait_for_decrypted_data`,
but when returning from `wait_for_decrypted_data` due to a new connection being reused in HTTP.jl,
the `handshake` was redone, which resulted in the `AssertionError` shown above.

The proposal here is that when monitoring idle connections, we only call `eof` on the underlying
TCPSocket, since we're really only concerned with knowing whether the core socket gets additional
data, encrypted or not, when we don't expect it.
@codecov-commenter
Copy link

codecov-commenter commented Aug 24, 2022

Codecov Report

Merging #912 (f013ddf) into master (786b1ee) will increase coverage by 0.12%.
The diff coverage is 100.00%.

❗ Current head f013ddf differs from pull request most recent head e8d6864. Consider uploading reports for the commit e8d6864 to get more accurate results

@@            Coverage Diff             @@
##           master     #912      +/-   ##
==========================================
+ Coverage   80.13%   80.26%   +0.12%     
==========================================
  Files          36       36              
  Lines        2915     2918       +3     
==========================================
+ Hits         2336     2342       +6     
+ Misses        579      576       -3     
Impacted Files Coverage Δ
src/ConnectionPool.jl 88.78% <100.00%> (+1.65%) ⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

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.

2 participants