-
Bug
-
Resolution: Fixed
-
P2
-
6u10
-
b23
-
generic
-
solaris
-
Verified
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.
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.
- relates to
-
JDK-6678929 Slow client JVM initialization at applet launch time (2)
-
- Resolved
-
-
JDK-6659079 Intermittent teardown and relaunch of applets using named pipe transport
-
- Closed
-
-
JDK-6676879 Nightly: Javaws Basic acceptans test (BAT.jnlp) failed on UNIX platforms in nightly build
-
- Closed
-
-
JDK-6661386 Passing illegal command-line arguments to applets causing browser hangs
-
- Closed
-
-
JDK-6651507 Implement named pipe transport for Windows
-
- Closed
-