Enviroment : ECperf 1.0 benchmark tests, Sybase's app server (EAServer 4.1.3), 1.4.1-beta (build 18) HotSpot VM with -server option, Windows 2000 5.00.2195 service pack 2.  

ECPerf 1.0 is a complicated benchmark. Basically, on our test condition there are around 400 EJB clients plus some http servlet clients doing the request to EAServer. The total number of threads may exceeds 1000. The detail could be found in  http://java.sun.com/j2ee/ecperf/

The system was in a complete hang state. Requests are all waiting for something. The end of the log file is the thread dump info, you don't need to look at the first part of the log file. 

I just tried Client VM, and it went through without hang. This was done on windows environmet. We did not set up the benchmark environment on Solaris. It is really complicated to setup the benchmark environment. You need 3 NT boxes to
do that.

Here is a list of the JVM options we used(exclude -D options)
  -server
 vfprintf
 exit
 abort
 -Xnoclassgc
 -verbose:gc
 -XX:NewSize=100M
 -XX:MaxNewSize=100M

Attached it the app server log.

Use client VM.

Customer found a workaround by rewriting part of their class loader logic.
Many thanks.

Duplicate of 4670071 java.lang.ClassLoader.loadClassInternal(String) is too restrictive.

The information provided in this bug will help us test 4670071.

  xxxxx@xxxxx   2002-08-07


Further work by   xxxxx@xxxxx   shows this bug is almost certainly
a duplicate of 
  4738340 Deadlock in the classloader loading, with out circular locking
(at least the logs/symptoms appear to be very similar).

Internal testing by   xxxxx@xxxxx   shows that the fix for 4738340
does indeed solve the problem here.  I'll wait for more verification
before marking this bug as a duplicate of 4738340.

  xxxxx@xxxxx   2002-10-21

Verified by customer to be fixed by 4738340. They had some concerns about
performance, but that was likely caused by the way the VM they tested was
built (this was a private build, not through our normal channels).

  xxxxx@xxxxx   2002-10-24