tomcat with https get a CLOSE_WAIT when directly TCP connect

Question

I use tomcat 8.5.4 to build a https based server on port 443 like this:

 94     <Connector
 95            protocol="org.apache.coyote.http11.Http11NioProtocol"
 96            port="8000" maxThreads="200"
 97            scheme="https" secure="true" SSLEnabled="true"
 98            keystoreFile="conf/rs_keystore.jks" keystorePass="ntsdawn"
 99            clientAuth="false" sslProtocol="TLS"/>

But a client use tcp to connect the port 8000, and then quickly close the tcp connection. After this, in my server the connection is CLOSE_WAIT status, and more important is, the CPU grows and the org.apache.tomcat.util.net.TLSClientHelloExtractor object was created very fast util the gc trigger:

root@nts32:/home/vcloud/apache-tomcat-8.5.4/logs# jmap -histo 14 | head

 num     #instances         #bytes  class name
----------------------------------------------
   1:       5159655      165108960  java.util.HashMap$Node
   2:          9138      131509512  [I
   3:       5148446      123562704  java.util.ArrayList
   4:       5145501      123492024  java.util.concurrent.LinkedBlockingQueue$Node
   5:       5145486      123491664  org.apache.tomcat.util.net.**TLSClientHelloExtractor**
   6:       3210008      102720256  java.util.concurrent.locks.AbstractQueuedSynchronizer$Node
   7:       2162508       86500320  java.util.HashMap$KeyIterator

And the connection will stay at CLOSE_WAIT forever....

But, if I modify the server.xml use http but not https like this:

 70     <Connector port="8000" protocol="org.apache.coyote.http11.Http11NioProtocol"
 71                connectionTimeout="20000"
 72                redirectPort="8443" />

Then every thing is OK. The TCP connect come and my server will reply the FIN when client send the FIN.

Is anything wrong of my https configuration?

Answer 1

There's a bug in tomcat 8.5.4 wherein TLS connections get into a loop when socket connection is dropped before TLS handshake is complete. Upgrading to tomcat 8.5.5 or above should fix this.

Below is the bug

https://bz.apache.org/bugzilla/show_bug.cgi?id=60035

Answer 2

There could be issue with HTTPs apache libs as well. From apache release notes of httpcore-osgi-4.4.11, I found two bugs fixed in "httpcore-osgi" library which are possibly related: Bug fix: corrected handling of graceful SSL session termination initiated by the opposite endpoint (back-ported from master). Contributed by Oleg Kalnichevski

Bug fix: corrected handling of NEED_WRAP handshake status during graceful SSL session termination
(back-ported from master).
Contributed by Oleg Kalnichevski <olegk at apache.org>

Link for reference: https://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES-4.4.x.txt