Re: Applet Hangs when submitting data to servlet
ILPTAB wrote:
I am currently supporting an interactive web site for a state agency.
Recently we started getting reports from SOME of the users that the
applet hangs when they attempt to submit data to the servlet running
on our web server. We have not made any changes to the java code so
the only thing I can figure is that it must be happening as a result
of an update to the java JRE or Windows. Note that I said it's
occurring with SOME of the users. Other people seem to be having no
problem at all with it.
To help illustrate the problem, I put together a small test server and
applet that demonstrates the problem. I have included the source code
for both parts below. On the applet side, it hangs when it comes to a
line that attempts to instantiate the ObjectInputStream class and
retrieve the input stream from the applet.
ObjectInputStream inobj = new ObjectInputStream(s.getInputStream());
Since the applet locks up, I am unable to give you any error messages
in the java console. In fact the browser gets so locked up that it
requires the user to close the session from the Windows task manager.
On the Servlet side it hangs at the line that attempts to read the
data stream from the socket connection.
sSearchField_ = in.readLine();
The error messages generated at the server are as follows:
Java.lang.NullpointerException at ServerSide.testLookup(ServerSide.54)
at ServerSide.run(ServerSide.java.98)
at jave.lang.thread.run(Unkown Source)
Any help in resolving this problem would be greatly appricated.
Thank you.
There may be a potential for a dead-lock situation in your input/output streams,
with the establishment of the ObjectOutputStream/ObjectInputStream.
Creating an ObjectOutputStream writes the stream header, and if this isn't
flushed the client may block in its ObjectInputStream constructor. Try adding a
flush() to the server ObjectOutputStream immediately after it's opened, before
reading the request from the client. The client ObjectInputStream constructor
might block reading the stream header which the server hasn't flushed.
Also, flushing the client PrintWriter *before* attempting to create the
ObjectInputStream might release the dead-lock. The server could be blocked
reading the request, so it hasn't got around to sending the response. If the
client request is flushed the server could complete reading the request and
send the response, thus effectively flushing the server ObjectOutputStream
stream header and releasing the client ObjectInputStream constructor.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555