When monitoring idle connections, only call eof on tcp socket #912
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In a heavy cloud storage workflow, I encountered the following error:
with traces back to calling
eof(::SSLContext)
frommonitor_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 callingeof
->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 theAssertionError
shown above.The proposal here is that when monitoring idle connections, we only call
eof
on the underlyingTCPSocket, since we're really only concerned with knowing whether the core socket gets additional
data, encrypted or not, when we don't expect it.