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

Adding SslCloseCompletionEventHandler to close channels on tls_close #1041

Merged
merged 2 commits into from
Jan 31, 2019

Conversation

spfink
Copy link
Contributor

@spfink spfink commented Jan 28, 2019

Description

Adds a new class to handle SslCloseCompletionEvents that occur when a SSL channel goes inactive and can no longer be used.

Motivation and Context

Fixes the case where an channel is in the pool but the server has sent a tls_close event for that channel.

Testing

Added test for handler.

Local testing significantly reduces the number of "Server Failed To Send A Complete Response" errors.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have read the README document
  • I have added tests to cover my changes
  • All new and existing tests passed
  • A short description of the change has been added to the CHANGELOG
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

  • I confirm that this pull request can be released under the Apache 2 license

@spfink spfink force-pushed the finks/ssl-close branch 2 times, most recently from 4830d8b to 7e2db6a Compare January 28, 2019 18:11
/**
* Handlers {@link SslCloseCompletionEvent}s that can are sent whenever an SSL channel
* goes inactive. This most commonly occurs on a tls_close sent by the server. Channels
* in this state can't be reused so we must close them.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Proofread.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know what I was writing here.

Copy link
Contributor

@millems millems left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did we verify this works in The Real World?

if (evt instanceof SslCloseCompletionEvent) {
ctx.close();
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this fix be pushed upstream to netty?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know, doing what we are doing here is standard practice. I'm not sure why Netty doesn't close the channel the SslHandler.

@spfink
Copy link
Contributor Author

spfink commented Jan 28, 2019

@millems, as far as real world verification, yes. I can reproduce the issue reliably on my local machine. This change significantly reduces the number of occurrences if not entirely.

It's still possible that S3 (or whoever) closes the connection after you picked it up from the pool and before reading/writing. We need to handle that case as well.

* in this state can't be reused so they must be closed.
*/
@SdkInternalApi
public class SslCloseCompletionEventHandler extends ChannelInboundHandlerAdapter {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor, might be worth creating a singleton across channels to reduce GC since this handler is stateless.

nit, final on this class

public class SslCloseCompletionEventHandler extends ChannelInboundHandlerAdapter {

@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to forward the event if it's not a SslCloseCompletionEvent?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Added.

@codecov-io
Copy link

codecov-io commented Jan 28, 2019

Codecov Report

Merging #1041 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #1041      +/-   ##
============================================
+ Coverage      55.7%   55.71%   +<.01%     
- Complexity     4610     4612       +2     
============================================
  Files           816      817       +1     
  Lines         27944    27950       +6     
  Branches       2251     2251              
============================================
+ Hits          15567    15572       +5     
  Misses        11657    11657              
- Partials        720      721       +1
Impacted Files Coverage Δ Complexity Δ
...nio/netty/internal/ChannelPipelineInitializer.java 37.5% <100%> (+1.32%) 4 <0> (ø) ⬇️
...netty/internal/SslCloseCompletionEventHandler.java 100% <100%> (ø) 3 <3> (?)
...are/amazon/awssdk/core/internal/util/Mimetype.java 78.04% <0%> (-2.44%) 14% <0%> (-1%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 42c476b...6dd73f6. Read the comment docs.

@spfink spfink merged commit d20a400 into master Jan 31, 2019
@spfink spfink deleted the finks/ssl-close branch March 17, 2020 23:41
aws-sdk-java-automation added a commit that referenced this pull request Nov 13, 2020
…7a594da51

Pull request: release <- staging/1cf99818-ab00-4966-b661-dae7a594da51
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.

5 participants