JDK-4725737 : REGRESSION: URLEncoder degraded performance in a multithreaded environment
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.0,1.4.1,1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,linux,solaris,solaris_8,windows_2000 generic,linux,solaris,solaris_8,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 2002-08-02
  • Updated: 2002-09-26
  • Resolved: 2002-09-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description

Name: gm110360			Date: 08/02/2002


FULL PRODUCT VERSION :
Solaris 64-bit:

java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

(The problem also appears in he 32-bit JDK).

Linux:

java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)


FULL OPERATING SYSTEM VERSION :
SunOS averia 5.8 Generic_108528-09 sun4u sparc SUNW,UltraAX-i2

ADDITIONAL OPERATING SYSTEMS :
Linux fora 2.4.18 #3 dl jun 3 14:55:25 CEST 2002 i686
unknown unknown GNU/Linux


A DESCRIPTION OF THE PROBLEM :
URLEncoder.encode shows severely degraded performance when
run concurrently by several threads.


REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached program under 1.4.1_02.

Using the 2-parameter encode() method will show similar
results (although you won't be able to compare with 1.3.1's
behaviour).

You can also observe this by trying to run a multi-threaded
test on Jakarta JMeter. See
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11369 for
details.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected:

$ time ~/jdk1.3.1/bin/java URLEncode

real
0m2.424s
user
0m1.040s
sys
0m0.100s

Actual:

$ time ~/j2sdk1.4.0/bin/java URLEncode

real
0m12.108s
user
0m5.330s
sys
0m0.290s


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class URLEncode extends Thread {
  public static void main(String args[]) {
    for (int i=0; i<10; i++) {
      new URLEncode().start();
    }
  }

  public void run() {
    for (int i=0; i<1000; i++) {
      String e= java.net.URLEncoder.encode("Aix? ?s una prova.");
    }
  }
}


---------- END SOURCE ----------

Release Regression From : 1.3.1_04
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 160216) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b03
14-06-2004

EVALUATION URLEncoder has been significantly enhanced in 1.4.x therefore it is expected to be somewhat slower. Whether the difference should be that significant is another story and we should look into it. But this hardly count as a regression. ###@###.### 2002-08-02 The main problem was the use of a BufferedWriter when writing. BufferedWriter only offers a performance improvement when writing to relatively a slow output mechanism, such as a socket or file, but not when writing to a byte array. This was introduced as part of the fix for 4407610, but can be backed out. A second problem was the fact that in 1.4 to fix 4407610, we changed the encoder behavior to be 100% consistent with the decoder and this required creating a separate encoder for each subsequence within the string that needs to be encoded. This introduces an element of overhead that is proportianal to the number of subsequences in the string to be encoded. The plan for this bug was to change this behavior as well so that only one encoder is used, but some JCK tests depend on this new behavior (even though it is not in the specification) so unfortunately this aspect has to stay. ###@###.### 2002-09-16
16-09-2002