This JDC comment is from bug # 4493399. It describes a problem caused by the siganling method between the browser side and vm side of the plugin.


2002-03-26 19:17:36
eudmare

The occsional total hanging of the Java Plugin on Solaris
was a show stopper for us, so we started debugging and
found what goes wrong:
Any Java Plugin to Netscape connection on Solaris will fail
if the request is larger than about 9000 Byte. This is
independent of the encryption used. The root cause is the
very poor implementation of the Java Plugin/Java-side to
Java Plugin/c-side communication: The Java Plugin wants to
write the whole request into a Unix pipe and afterwards
notify the c-side of the Plugin implementation via X-
property setting that a request is ready to be read out of
the pipe. But on the c side the process is not reading the
pipe until the X-property has changed. Therefore the pipe
gets full during the write and then the Plugin thread gets
suspended so it will never tell the c side to start reading
the pipe!!!!! Aua! In fact this implementation is using the
pipe just as a fixed size buffer, not as a pipe at all!
The little more than 9000 Bytes come from the fact that the
default Solaris pipe buffer size is 10 x 512 Bytes each for
the reading and writing side as can be checked via "ulimit -
a". Some overhead in the pipe mechanism yields 91xx
something Bytes. The count does include also Plugin trace
messages which are sent around the request and request
headers, so you end up being able to send about 6000 Bytes
in the form. Unfortunatley, the buffer size cannot be
changed easily on Solaris and would cause huge memory
overhead for all other pipe using processes.
Things get even worse when for some other event reason
(page close?) the c-side is triggered again to handle
reuqests: the c-side is also not made for actually reading
out of a pipe in the real sense. As soon as the pipe is
actually filled with more than the buffer length, the c-
side will start interpreting user data as request
ids/request data as it thinks that whenever it has done an
exhausing read of the pipe, the next data is the start of a
new request!! Aua, aua again!!! Things go really wrong
then. (Unknown request-id whatever, exit (6), crashes, ...)
Fortunately, the new plugin 1.4.0 uses it's own https
connections, so this -peep- code is never called in the
latest version. Thank God! However, it is still active for
non https connections. Good luck to all http users!
As painfull as the consequence is: All our Solaris users
now have to upgrade to 1.4.0 to get rid of this bug.
Martin Renschler (thanks to Gerd Rausch) Ericsson Berkeley