[ 
https://issues.apache.org/jira/browse/HTTPCORE-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17264045#comment-17264045
 ] 

Yannick Dylla commented on HTTPCORE-658:
----------------------------------------

[~olegk] I think you should change it everywhere.

I could also reproduce the "Socket is closed" Exception with AdoptOpenJDK 
1.8.0_275 but note that the logging level for this is only WARNING instead of 
SERVE like for the "closing inbound before receiving peer's close_notify" 
Exception.
So I would still see the fix as an improvement.

But further when I try it with an old OpenJdk 1.8.0_181 the issue is also 
fixed. No warning or exceptions anymore.
For me it looks like a bug in AdoptOpenJDK 1.8, how else would you close the 
Socket if not with its close function?

And lastly the selfish reason we are probably not able to upgrade to 5.x soon, 
so a fix in 4.4.x would be nice :D

> Closing a connection triggers a javax.net.debug error to be logged
> ------------------------------------------------------------------
>
>                 Key: HTTPCORE-658
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-658
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore
>    Affects Versions: 4.4.13
>            Reporter: Yannick Dylla
>            Priority: Minor
>         Attachments: tls-close-bug.zip
>
>
> Hi,
>  I noticed that on each SSL/TLS Connection closing the following Exception is 
> logged when {{-Djavax.net.debug=ssl}} is enabled:
> {noformat}
> javax.net.ssl|ERROR|01|main|2021-01-11 11:38:11.259 
> CET|TransportContext.java:318|Fatal (INTERNAL_ERROR): closing inbound before 
> receiving peer's close_notify (
> "throwable" : {
>   javax.net.ssl.SSLException: closing inbound before receiving peer's 
> close_notify
>         at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
>         at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>         at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:313)
>         at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269)
>         at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:260)
>         at 
> java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:737)
>         at 
> java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:716)
>         at 
> org.apache.http.impl.BHttpConnectionBase.close(BHttpConnectionBase.java:325)
>         at 
> org.apache.http.impl.conn.LoggingManagedHttpClientConnection.close(LoggingManagedHttpClientConnection.java:81)
>         at 
> org.apache.http.impl.conn.CPoolEntry.closeConnection(CPoolEntry.java:70)
>         at org.apache.http.impl.conn.CPoolEntry.close(CPoolEntry.java:96)
>         at 
> org.apache.http.pool.AbstractConnPool.shutdown(AbstractConnPool.java:149)
>         at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.shutdown(PoolingHttpClientConnectionManager.java:430)
>         at 
> org.apache.http.impl.client.HttpClientBuilder$2.close(HttpClientBuilder.java:1244)
>         at 
> org.apache.http.impl.client.InternalHttpClient.close(InternalHttpClient.java:201)
>         at TLSCloseBug.main(TLSCloseBug.java:83)}
> )
> {noformat}
> I tracked down the Problem to the BHttpConnectionBase.close code, where 
> socket.shutdownOutput and socket.shutdownInput are called before 
> socket.close().
>  Why is that? The code is pretty old so maybe it was required at some point.
>  But for the JDK 11 SSLSocketImpl this triggers the error to be logged.
>  In general, I think it would be better to remove the shutdownOutput and 
> shutdownInput calls and only rely on the {{Closeable}} contract to clean up 
> the socket.
>  For the JDK 11 SSLSocketImpl this would fix the Problem.
> I also wrote a small example app to trigger the error: [^tls-close-bug.zip]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to