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
KAFKA-7505: Process incoming bytes on write error to report SSL failures #5800
KAFKA-7505: Process incoming bytes on write error to report SSL failures #5800
Conversation
// exception, but continue to handle the handshake failure as an authentication exception. | ||
try { | ||
if (flush) | ||
flush(netWriteBuffer); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously, we would not throw the exception if flush
returned false
, but now we do. I assume that's intentional? May be worth explaining.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ijuma Thanks for the review. Sorry that was unintentional, updated code and comment.
For my understanding, the behaviour in Java 11 has changed? |
@ijuma I think there are changes in Java 11 which is causing these failures - I can recreate very easily with Java 11 but not with other versions. And we haven't seen these failures in the other builds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just a minor comment. No re-review needed.
} catch (SSLException e1) { | ||
maybeProcessHandshakeFailure(e1, false, e); | ||
} | ||
} | ||
|
||
} while (netReadBuffer.position() > 0 && read > 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed this offline with @rajinisivaram and we think we think the first condition can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ijuma Thanks for the review, updated.
@rajinisivaram, it seems like this doesn't fix all issues:
|
84f3e33
to
cbed4b1
Compare
@ijuma |
retest this please |
cbed4b1
to
136a62f
Compare
retest this please |
@ijuma Haven't hit the issue with the last 3 builds though there have been some unrelated build failures. If you are ok with the change, shall I merge it? |
retest this please |
// handshakeUnwrap unwraps data in the buffer, looping until handshakeStatus != NEED_UNWRAP. Here we | ||
// want to process all incoming data regardless of handshakeStatus. If some data was unwrapped, but | ||
// there is more remaining, try again while `handshakeUnwrap` is able to unwrap any data. | ||
unwrappedAvailable = position != netReadBuffer.position() && netReadBuffer.position() != 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be simpler if we passed a parameter to handshakeUnwrap
to control whether the handshake status was checked or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ijuma Thanks for the review, updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@ijuma Thanks for the review, merging to trunk and 2.1. |
…res (#5800) Reviewers: Ismael Juma <ismael@juma.me.uk>
…res (apache#5800) Reviewers: Ismael Juma <ismael@juma.me.uk>
…res (apache#5800) Reviewers: Ismael Juma <ismael@juma.me.uk>
Committer Checklist (excluded from commit message)