DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40423>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40423

           Summary: APR connector performance
           Product: Tomcat 5
           Version: 5.5.17
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Connector:HTTP
        AssignedTo: [email protected]
        ReportedBy: [EMAIL PROTECTED]


Under high ssl loads (SPECweb2005 Banking application) the acceptor thread
temporally (60s approx.) stops accepting new connections. The Acceptor thread
blocks (see above the stacktrace) waiting for client data to finish the ssl
handshake, but the client has closed the connection due a connection timeout, so
it never sends the data. All the subsequent handshakes also block because the
clients that are waiting to establish a connection get canceled too.

This behavior prevents the server from accepting any new connections and greatly
degrades the performance of the APR connector.

A possible workaround maybe to let the Acceptor thread only accept the
connection and the Worker threads call to setSocketOptions() (only the first
time). This change will improve the robustness and scalability of the connector.

Regards,

- Vicenç

PS: IMHO this is an ugly workaround and the whole threading model of the APR
connector should be re-thought.





Name: http-8443-Acceptor-0
State: RUNNABLE
Total blocked: 4  Total waited: 84

Stack trace:
org.apache.tomcat.jni.SSLSocket.handshake(Native Method)
org.apache.tomcat.util.net.AprEndpoint.setSocketOptions(AprEndpoint.java:850)
org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:1004)
java.lang.Thread.run(Thread.java:797)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to