JDK-4283017 : socketRead/socketWrite appears to hang
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.2.1
  • Priority: P5
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_2.6
  • CPU: sparc
  • Submitted: 1999-10-20
  • Updated: 2001-03-28
  • Resolved: 2001-03-28
Related Reports
Relates :  
JDK-4032593 - read() on a socket fails
Description
this bug is created by java platform CTE for issues we worked with
Heatheon/WebMD, the Heathon escalation 522444 used to point to bug 4032593

customer wrote a java webserver running on solaris, it accepts an incoming
HTTP request then use a thread to read in the request, process it, and send
out a reply.

they complain that they often see some of these worker thread stuck in
SocketInputStream.socketRead or SocketOutputStream.socketWrite for long
time.
Comments
EVALUATION read: read is a blocking call if the setSoTimeout has not been called. so if there is no data sent from the other side the read will hang forever if the client close the connection without sending data. the read will get an exception, but it's possible that the client just goes away without sending the expected disconnect sequence (TCP FIN or RST), in this case the connection will be left half open and the way this kind of connection is dealt with depend on the underlying TCP module, on solaris, reading from a half open connection might hang forever, unless the KEEPALIVE option is set for this socket (default off) using setSoTimeout should also get out of readSocket if there is no data being sent within the specified timeout. but the customer complains sometimes the setSoTimeout doesn't always work(we haven't confirm that yet) write: if the client is not reading data fast enough, and server keeps writing to the socket, it will eventually be stopped because of flow control. this is also dependent on the underlying TCP module. (there is currently no java api to control the timeout for write, setSoTimeout is only for read) on solaris there is an tcp parameter tcp_ip_abort_interval to control how long will it wait to abort the connection if a packet hasn't been acknowledged for that amount of time. it can be tuned using "ndd" command. but even with that a dribbling connection can still make write hang for long time. the best way to control this (both read/write) seems to be using another thread to monitor how long the read/write thread has stay in there, then use Thread.interrupt() to interrupt the reading/writing thread. so far we haven't found any bug in java on this escalation. tao.ma@Eng 1999-10-20
20-10-1999