App Server 8.2

We have some performance problem when dealing with SSL requests.

Namely after some period of time, SSL clients connections from clients are not accepted.

The interesting thing is that from one specific client there are a lot of TCP connections for SSL which are in CLOSE_WAIT state. When analyzing stack traces, selector thread is in RUNNABLE state and worker-threads are in

WAIT(they wait beacuse task is not assigned). Bellow you find stack trace and netstat output.

Is this the case for DOS attacks? It might be the situation when clients have some viruses.

Platform: Windows 2003 Sever SP1

Sun Application Server 8.2 PE with shiped JDK

Stack trace for selector-thread:

Name: SelectorThread-443

State: RUNNABLE

Total blocked: 9 Total waited: 3

Stack trace:

sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)

sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:275)

sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java: 257)

sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:138)

sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

com.sun.enterprise.server.ss.ASSelector.select(ASSelector.java:92)

com.sun.enterprise.server.ss.ASInputStream.waitForSelect(ASInputStream.java:101 )

com.sun.enterprise.server.ss.ASInputStream.read(ASInputStream.java:81)

com.sun.enterprise.server.ss.ASInputStream.read(ASInputStream.java:73)

com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:284)

com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:319)

com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:720)

com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImp l.java:1025)

com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:10 38)

org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.j ava:118)

com.sun.enterprise.web.connector.grizzly.SelectorThread.startBlockingMode(Selec torThread.java:1180)

com.sun.enterprise.web.connector.grizzly.SelectorThread.startEndpoint(SelectorT hread.java:1124)

com.sun.enterprise.web.connector.grizzly.SelectorThread.run(SelectorThread.java :1098)

- --

Netstat output for https:

TCPwwzoon:https83.6.111.80:63876CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1201CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1202CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1203CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1204CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1205CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1206CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1207CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1208CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1209CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1210CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1211CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1212CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1213CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1214CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1215CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1216CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1217CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1218CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1219CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1220CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1221CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1222CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1223CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1224CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1225CLOSE_WAIT

TCPwwzoon:https83.15.89.62:1226CLOSE_WAIT

TCPwwzoon:https83.15.243.11:61540CLOSE_WAIT

TCPwwzoon:https83.17.34.154:1368ESTABLISHED

TCPwwzoon:https83.17.34.154:1825ESTABLISHED

TCPwwzoon:https83.17.34.154:1864CLOSE_WAIT

TCPwwzoon:https83.17.34.154:1975CLOSE_WAIT

TCPwwzoon:https83.17.34.154:2092CLOSE_WAIT

TCPwwzoon:https83.17.34.154:3199CLOSE_WAIT

TCPwwzoon:https83.17.34.154:3829ESTABLISHED

TCPwwzoon:https83.17.34.154:3996CLOSE_WAIT

TCPwwzoon:https83.17.34.154:5375CLOSE_WAIT

TCPwwzoon:https83.17.34.154:5884CLOSE_WAIT

TCPwwzoon:https83.17.34.154:6254CLOSE_WAIT

TCPwwzoon:https83.17.34.154:6259CLOSE_WAIT

TCPwwzoon:https83.17.34.154:6339ESTABLISHED

TCPwwzoon:https83.17.34.154:7048CLOSE_WAIT

TCPwwzoon:https83.17.34.154:7539CLOSE_WAIT

TCPwwzoon:https83.17.34.154:7788CLOSE_WAIT

TCPwwzoon:https83.17.34.154:7978CLOSE_WAIT

TCPwwzoon:https83.17.34.154:8630CLOSE_WAIT

TCPwwzoon:https83.17.34.154:8792CLOSE_WAIT

TCPwwzoon:https83.17.34.154:8941CLOSE_WAIT

TCPwwzoon:https83.17.34.154:8950ESTABLISHED

TCPwwzoon:https83.18.74.211:1072CLOSE_WAIT

TCPwwzoon:https83.31.149.218:3305CLOSE_WAIT

[4995 byte] By [marcin.jarzab] at [2007-11-26 10:29:42]
# 1
Can you try adding this to your jvm-options:-Dcom.sun.enterprise.server.ss.ASQuickStartup=false-Scott
sdo at 2007-7-7 2:35:40 > top of Java-index,Application & Integration Servers,Application Servers...
# 2
I've noticed this too, but only in 8.2 PE on Solaris.Running JDK 1.5_07Will try the ASQuickStartup=false suggestion, but it looks like a bug as I've got hundreds of SSL connections in CLOSE_WAIT state.
tourtech at 2007-7-7 2:35:40 > top of Java-index,Application & Integration Servers,Application Servers...