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
Add StacklessSSLHandshakeException
for ClosedChannelException
#13099
Conversation
4409fd6
to
705dbea
Compare
@hyperxpro can you please revert the formatting changes ? |
lmao, I have no idea how they happened, reverting. XD |
bc44113
to
dbc23da
Compare
;/ Whats wrong with CI? |
@hyperxpro can you rebase ? |
dbc23da
to
e4f47fb
Compare
Done |
Finally :3 Tests passed. |
@vietj any concerns ? |
On the second though, can you please elaborate how knowledge of the fact that the connection was closed during handshake (not before or after) is helping with debugging this case? I'm a bit concerned that this changes existing behavior and some users potentially may already have logic that handles it correctly. To me, throwing |
The reason is that when This is a snap from Spring Boot WebFlux which uses Reactor Netty under the food.
I have already mentioned the issue with this log in my PR description. |
Thanks! I saw the issue before and looked at all the linked pages. Will it help if we replace
|
Changing null with the message was the first top choice but I agree it will break users who rely strongly on |
How about stackless SSLHandshakeException was sub-cause of |
I see, I just realized that |
Yeah, that sounds better. A stackless exception cause Should I proceed with this? |
Just to double check we are on the same page:
I'm + 💯 for this |
@idelpivnitskiy why not just use |
It's hard to say that the cause of |
@idelpivnitskiy true... so @hyperxpro do what @idelpivnitskiy suggested for 4.1. I think for main we want to do the change of using |
1aafab9
to
26fb687
Compare
e99ff0f
to
1aafab9
Compare
1aafab9
to
cf14ccc
Compare
Ready @idelpivnitskiy @normanmaurer |
Help help help ;/
|
Ufff... |
I see that there is |
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.
I think for main we want to do the change of using SslHandshakeException
@normanmaurer I still feel like ClosedChannelException
is more important than SslHandshakeException
in this scenario. It means that the channel was closed and in most cases it doesn't matter if it was before/in-the-middle/after the handshake. I don't think my debugging flow would change in any of 3 cases.
If you would like to change that in Netty 5, we should do that consistently for any other case when we throw ClosedChannelException
. There are a few related to HTTP/2, WebSockets, etc. If we go that route, that's probably worth making as a separate effort.
handler/src/main/java/io/netty/handler/ssl/StacklessSSLHandshakeException.java
Outdated
Show resolved
Hide resolved
How about WDYT? |
Imho if we go that round, we have to change any other handler in the same situation. Those also have to throw Http2Exception, WebSocketHandshakeException, EncoderException (brotli), etc. with |
Alright, I get that now. How about But I am not sure how reliable is this dual approach. Should we do some sort of poll and ask users what they think? Because this is really confusing. From a technical perspective, If Should we play with reflections in this? Or actually, contribute the ability to pass the Contributing to Java seems overkill but actually feels right because |
+1 on proposing more constructors for
Will this be significantly more helpful for users compare to the approach in this PR? To my knowledge (unless I miss anything) |
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.
Thanks for bringing extra context for users!
Co-authored-by: Idel Pivnitskiy <idel.pivnitskiy@apple.com>
@franz1981 What do you feel? Can you call some of your friends who are core contributors of JDK? I'd like some more suggestions and feedback before I actually go ahead with patch for JDK. |
StacklessSSLHandshakeException
for ChannelClosedException
StacklessSSLHandshakeException
for ChannelClosedException
StacklessSSLHandshakeException
for ClosedChannelException
@hyperxpro @idelpivnitskiy thanks a lot! |
…3099) Motivation: When a channel is closed during the SSL handshake then `java.nio.channels.ClosedChannelException` is thrown. This is correct when we see it from a low-level transport perspective but from a high-level, this error is not detailed enough to debug. And when we log `ClosedChannelException`, we get this line: `java.nio.channels.ClosedChannelException: null` in the stack trace. Modification: To combat this, we should throw `StacklessSSLHandshakeException` with the message `"Connection closed while SSL/TLS handshake was in progress"` as suppressed with`ClosedChannelException`. This will explicitly declare that the handshake failed due to connection closure. Result: Fixes #12000 Co-authored-by: Idel Pivnitskiy <idel.pivnitskiy@apple.com>
Motivation:
When a channel is closed during the SSL handshake then
java.nio.channels.ClosedChannelException
is thrown. This is correct when we see it from a low-level transport perspective but from a high-level, this error is not detailed enough to debug. And when we logClosedChannelException
, we get this line:java.nio.channels.ClosedChannelException: null
in the stack trace.Modification:
To combat this, we should throw
StacklessSSLHandshakeException
with the message"Connection closed while SSL/TLS handshake was in progress"
as suppressed withClosedChannelException
. This will explicitly declare that the handshake failed due to connection closure.Result:
Fixes #12000