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

            Bug ID: 64194
           Summary: POST requests with large bodies fail sporadically
                    since change to read and write for NIO
           Product: Tomcat 9
           Version: 9.0.31
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Util
          Assignee: dev@tomcat.apache.org
          Reporter: sebastian.r...@sap.com
  Target Milestone: -----

Created attachment 37057
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=37057&action=edit
stacktrace

We run our Jenkins (2.204.3) inside tomcat 9.0.x using a more-or-less default
tomcat configuration:

    <Connector port="8443"
               scheme="https"
               URIEncoding="UTF-8"
               maxThreads="200"
               secure="true"
               SSLEnabled="true">
        <SSLHostConfig
truststoreFile="${user.home}/tomcat/keystore/keystore-test.p12"
                       truststoreType="PKCS12"
                       truststorePassword="<snip>"
                       certificateVerification="optional"
                       protocols="TLSv1.1,TLSv1.2">
            <Certificate
certificateKeystoreFile="${user.home}/tomcat/keystore/keystore-test.p12"
                         certificateKeystoreType="PKCS12"
                         certificateKeystorePassword="<snip>"
                         certificateKeyAlias="<snip>" />
        </SSLHostConfig>
    </Connector>

We use Sapmachine 11.0.5 as JDK.


After upgrading from 9.0.30 to 9.0.31, many POST requests with a large request
body fail (see attached stacktrace.txt).


I git-bisected the problem between 9.0.30 and 9.0.31:

5bdd7d4712fac4e1af47421c3600b18fabc22ed6 is the first bad commit
commit 5bdd7d4712fac4e1af47421c3600b18fabc22ed6
Author: remm <r...@apache.org>
Date:   Mon Dec 9 15:15:00 2019 +0100

    Simplify blocking read and write for NIO

    This does not remove or cleanup any of the code that is now unused
    (NioSelectorPool, NioBlockingSlector, channel flush method, fields,
    etc), it will be done after actual review.
    I do not see any negative performance impact. Note: for performance
    testing, use HTTP/1.1 (avoiding sendfile).

:040000 040000 aedcc7bbeb0c0c18a989bea5911e71388733d824
423e2f52c347542a402c8c084e18ae84daca1c11 M      java
:040000 040000 ef36ef5dd46aea9673999788a9178b50e7dceb29
d2ade377eac7f26968bd51c24113051a68bb8875 M      webapps


This also fits the stack trace elements
                at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1639)
                at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

Depending on the network connection I am on (direct, VPN, ...) the problem
occurs more or less often.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to