JDK-8044726 : Performance issue seen with HttpURLConnection.setFixedLengthStreamingMode()
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 7u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86_64
  • Submitted: 2014-05-31
  • Updated: 2015-09-07
  • Resolved: 2015-09-07
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux localhost 3.11.10-100.fc18.x86_64 #1 SMP Mon Dec 2 20:28:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
When the fixedContentLength is set with HttpURLConnection.setFixedLengthStreamingMode(), 
sun.net.www.protocol.http.HttpURLConnection.getOutputStream() is about 6 times slower than the jdk7u25 with fixedLengthStreamingMode is enabled. I checked several jdk7 version , this is introduced since jdk7u40. 

REGRESSION.  Last worked in version 7u25

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1  connection.setFixedLengthStreamingMode(length);
2. connection.getOutputstream()
3. compare the getOutputStream with jdk7u60 , jdk7u40 and jdk7u25


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
jdk7u60 can get same performance with jdk7u25 to getOutputStream with fixedLengthStreamingMode enabled. 
ACTUAL -
jdk7u60 is much slower than jdk7u25 to getOutputStream from HttpURLConnection.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
         HttpURLConnection connection = (HttpURLConnection)url.openConnection();
        connection.setRequestMethod("POST");
        connection.setDoInput(true);
        connection.setDoOutput(true);
     
        connection.setFixedLengthStreamingMode(requestBody.length());
        
        connection.setRequestProperty("Content-Type", "text/xml; charset=UTF-8");
        connection.setRequestProperty("Accept", "*/*");

        connection.connect();
        long start = System.currentTimeMillis();
        OutputStream outputStream = connection.getOutputStream();
        long end = System.currentTimeMillis();
---------- END SOURCE ----------


Comments
Closing this out as will not fix. JDK-7199862 was an attempt to mitigate a problem with HTTP streaming POSTs (which cannot be retried) where a peer was closing a connection early due to misconfigured keep-alive handling. The fix checks to see if the connection is still alive before proceeding to use it. Unfortunately this required some extra overhead which is the cause of this bug. Setting the http.keepAlive property to false would workaround this issue but unfortunately the fix for JDK-7199862 can't be backed out.
07-09-2015

adding a standalone test
20-08-2015

the extra checking in 8000410 is the cause of the problem: (HttpClient.available()) http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/e6dc1d9bc70b
20-08-2015

There's a reproducer here: https://github.com/jimma/jdk7u40-httpurlconnection-issue
03-02-2015

No response was received from the submitter. As there is not enough information in this report to make headway it is being closed. If this issue is seen, please open a new report with all necessary information. This report ID can be referenced.
03-09-2014

Mail was sent to submitter requesting more information.
18-08-2014

Unfortunately I couldn't reproduce the problem. I'm thinking there may be something about the specific request that could help trigger this. If the filer could provide a full working test and a few details about the server I'd like to have another go. The only semi-related change in 7u40 I could find was http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/39e5407de46f
09-07-2014