Hi, On Mon, Dec 2, 2019 at 7:36 PM Xuelei Fan <xuelei....@oracle.com> wrote: > > Hi, > > Could someone please help to verify if the attached patch (JDK 14) works > HttpComponents?
I'm not sure I see the difference between a generic IOException and SSLHandshakeException. If a client is connecting to a busy proxy that sends a TLS close_notify to the client, that would be a SSLHandshakeException even though it may be actually possible to retry and get a successful connection and TLS handshake. On the other hand, if a busy proxy sends a FIN to the client, that would be an IOException that may or not succeed when retried. Or the server is running out of file descriptors, very likely will be reported as an IOException, but retrying won't help. Or the client is running out of file descriptors. Or the client cannot connect to the server (again, a retry may or may not be successful). Bottom line is that for both cases (IOException and SSLHandshakeException) a retry may be successful and as such client code will have a hard time to detect when or not to retry in either case. SSLException (and subclasses) do not report the TLS AlertDescription code, so it won't be possible to know the exact reason for the SSLHandshakeException, and from it decide whether it's retryable or not. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
