Bug 60555 - run by ssl and port:443 close_wait
Summary: run by ssl and port:443 close_wait
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Connectors (show other bugs)
Version: 8.5.4
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2017-01-05 09:41 UTC by hiki
Modified: 2017-08-09 14:38 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description hiki 2017-01-05 09:41:00 UTC

our service use springboot '1.4.0.RELEASE'
centos 6.5


After start, then use shell :
while true ;
	curl -k https://IP/app/current/queryCurrent.action	
	echo ""

and exec the command : netstat -antp | grep CLOSE_WAIT 
tcp        0      0 ********::443            ********:45138         CLOSE_WAIT  21773/java          
tcp        0      0 ********::443            ********::44910         CLOSE_WAIT  21773/java          
tcp        0      0 ********::443            ********::44464         CLOSE_WAIT  21773/java          
tcp        0      0 ********::443            ********::45234         CLOSE_WAIT  21773/java          
tcp        0      0 ********::443            ********::43768         CLOSE_WAIT  21773/java          
tcp        0      0 ********::443            ********::44216         CLOSE_WAIT  21773/java 

run without ssl no problem

code line 1399 in org.apache.tomcat.util.net.NioEndpoint
Using HTTP always get true
and When CLOSE_WAIT appears always "handshake == SelectionKey.OP_READ" and never change(Even if the client is closed)

These CLOSE_WAIT lived for more than 12 hours yet
Comment 1 Mark Thomas 2017-01-05 20:37:36 UTC

*** This bug has been marked as a duplicate of bug 60035 ***
Comment 2 hiki 2017-01-06 10:08:57 UTC
Thanks. Has been upgraded to 8.5.6 and the problem is solved
Comment 3 hiki 2017-01-06 10:45:25 UTC
(In reply to Mark Thomas from comment #1)
> *** This bug has been marked as a duplicate of bug 60035 ***

Thanks ,the problem is solved,
but I don't think the relationship with r1746551 is direct
I think the main solution to this problem is the following code


                        if (socket.isHandshakeComplete()) {
                            // No TLS handshaking required. Let the handler
                            // process this socket / event combination.
                            handshake = 0;
                        } else if (event == SocketEvent.STOP || event == SocketEvent.DISCONNECT ||
                                event == SocketEvent.ERROR) {
                            // Unable to complete the TLS handshake. Treat it as
                            // if the handshake failed.
                            handshake = -1;
                        } else {
                            handshake = socket.handshake(key.isReadable(), key.isWritable());
                            // The handshake process reads/writes from/to the
                            // socket. status may therefore be OPEN_WRITE once
                            // the handshake completes. However, the handshake
                            // happens when the socket is opened so the status
                            // must always be OPEN_READ after it completes. It
                            // is OK to always set this as it is only used if
                            // the handshake completes.
                            event = SocketEvent.OPEN_READ;
Comment 4 Vaibhav Bhandari 2017-08-04 20:45:16 UTC
@hiki's comments seems right and thats why a port to 7.0 line would be needed. We have hit this issue in 7.0 tomcat version.
Comment 5 Vaibhav Bhandari 2017-08-08 11:03:09 UTC
Reopening as porting to 7.0 version is needed.
Comment 6 Vaibhav Bhandari 2017-08-09 07:18:40 UTC

This is the change that needs to be ported to 7.0
Comment 7 Mark Thomas 2017-08-09 14:38:48 UTC
This report, as originally described, is not reproducible on Tomcat 8.0.x and earlier. While sockets in CLOSE_WAIT are observed, they do not remain in that state for more than a few seconds. Further, analysis of this issue with 8.5.x/trunk showed that it was introduced by r1746551 and that r1757903 was the correct fix for that issue.

You can not be observing the same problem on 7.0.x, even if the symptoms are identical, as r1746551 was not back-ported to 8.0.x or earlier.

Since the root causes are different there is no basis to conclude that the required fix is the same.

Please open a new issue and provide the steps to reproduce on a clean install of the latest stable release of any of the supported branches (currently 7.0.x, 8.0.x, 8.5.x and 9.0.x).