JDK-6678865 : Long command lines or applet parameter lists break new plug-in on Windows
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: generic
  • Submitted: 2008-03-22
  • Updated: 2010-09-08
  • Resolved: 2008-06-14
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.
JDK 6
6u10 b23Fixed
Related Reports
Relates :  
JDK-6678929 - Slow client JVM initialization at applet launch time (2)
Relates :  
JDK-6659079 - Intermittent teardown and relaunch of applets using named pipe transport
Relates :  
JDK-6651507 - Implement named pipe transport for Windows
Relates :  
JDK-6661386 - Passing illegal command-line arguments to applets causing browser hangs
Relates :  
JDK-6676879 - Nightly: Javaws Basic acceptans test (BAT.jnlp) failed on UNIX platforms in nightly build
Description
On Unix, the minimum POSIX command line length is 4096.
Having our extreme test case
http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6676879/JNLPLongProperties0.3.rel.html,
which tries to assemble considerable insane long JVM startup arguments.
The client message serializer get's out of order with the message stream.
It digests the JMVID, including the very long JVM argument list,
which might already breaks the serializer state.
Then it recognizes the following StartAppletMessage ID, 
but bails out then immediatly, since all followup bytes are misinterpreted,
or out of order.

This behavior was discovered while adding the mentioned stress commandline test
for CR 6676879, which adds validation code in this respect.
The fix for 6678929 fixed this problem on Unix platforms. Apparently there was a bug with the SocketTransport used to communicate between the browser-side code and the attached JVM that was the root cause. On Unix platforms, Unix domain sockets are now used, which are analogous to the named pipes currently used on the Windows platform.

There appears to be a residual bug in the named pipe implementation on Windows (see 6651507) causing breakage of the transport when a large amount of data is sent over. The following forum thread highlights this issue:

http://forums.java.net/jive/thread.jspa?threadID=39013&tstart=0

Investigating this with high priority as it indicates a deep problem.
Comments
SUGGESTED FIX webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6678865.0 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6678865/
14-04-2008
EVALUATION When the named pipe transport was implemented for Windows under 6651507, some deadlocks were discovered due to poor behavor of the Windows APIs. Workarounds were developed at the time involving the addition of more threads, as well as an initial write buffer to hold the results of the first few messages from the browser to the client attached JVM, which was found to be necessary at one point in the development to avoid deadlocks. Investigation of the customer's report for this bug indicated that this initial write buffer was getting corrupted. Initially we believed that the data being sent over the named pipe was being corrupted, but detailed investigation revealed that this was not the case. The corruption occurred at the point when the initial write buffer filled up and we were forced to wait for a connection from the client in order to flush it to the named pipe. Thanks to ###@###.### for the idea to completely remove the initial write buffer, which is possible at this time because the background connection thread already present handles the deadlock case the initial write buffer was originally intended to fix. My original fix involved expanding the initial write buffer to a list of buffers, which also solved the problem but added significant complexity, now understood to be unnecessary. Some other minor cleanups were made in the WindowsNamedPipe implementation in the spirit of robustness although they were not the root cause of this bug. While investigating this bug, two other issues were uncovered. First, the filtering of disabled JREs in the JVMManager was occasionally removing the wrong JRE in the case that two different copies of the same JRE were present in deployment.properties, one disabled, one enabled. Second, there was a lurking synchronization bug in the SerializingTransport base class where subclasses could inadvertently break the critical synchronization around serialization of messages. This is very likely the reason the earlier SocketTransport was failing on the same test case. Also deleted a few files that were intended to have been deleted in previous putbacks. This fix was tested with the regression tests for related bugs 6659079 and 6661386 as well as a new targeted test case.
14-04-2008
EVALUATION See suggested fix ..
09-04-2008
SUGGESTED FIX Dropping the non-blocking SocketTransport for Unix, and using the unix AF_UNIX sockets to implementent the unix variant of NamedPipe (Unix Domain Sockets). This is done in the performance fix, see: CR 6678929
09-04-2008
WORK AROUND We currently restrict the maximum command line length to 2047, which is the maximum for Windows 2k and NT4.
22-03-2008