This will probably close up everything. In sockets,
the socket is still valid when this exception is propagated
up, but we'll probably shut everything down. Should address
for tiger.

###@###.### 2001-08-23

Name: nt126004 Date: 11/04/2002


FULL PRODUCT VERSION :
bash-2.05a# /opt/j2sdk1.4.0_01/bin/java -version
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)
 


FULL OPERATING SYSTEM VERSION :
bash-2.05a# uname -a
Linux fetor 2.4.18 #2 Mon Aug 5 22:18:19 PDT 2002 i686
unknown
 
ADDITIONAL OPERATING SYSTEMS :
This bug affect any OS, because it's in a pure java API

EXTRA RELEVANT SYSTEM CONFIGURATION :
using the default SUN JSSE Provider JCE/JSSE
implementation, and quite posibly any other
implementation.

A DESCRIPTION OF THE PROBLEM :
When setSoTimeout() is called on an SSLSocket with a value
greater than 0, a InterruptedIOException is throw when
read() is called on it's InputStream when the SO_TIMEOUT
has occured (as expected). The problem is that any call
to read() after that returns -1, denoting that the
stream\socket has been closed.
  
Basically the SSLSocket inherits from Socket but does not
abide by the same rules as the Socket.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Make a server that uses SSLSocket
2. Write a client for connecting to it.
3. In the client code, do this:
   
try {
  sslSock.setSoTimeout(1000); // 1 second
  InputStream ips = sslSock.getInputStream()
  while (true) {
    try {
       int b = ips.read();
       if (b==-1) {
          break; // the socket was closed
       }
    } catch(InterruptedIOException iioe) {
        // SO_TIMEOUT causes this, this is ok
    }
      
} catch(IOException e) {
   // an error occured, or the socket was closed
}

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected:
      When setSoTimeout() is set to a value greater than 0
on an SSLSocket, read() should through an
InterrupteIOException when the timeout has been reached,
the next call to read() should NOT return -1 unless the
socket has been closed.
  
  
Actual:
   When read() is called after an InterruptedIOException
is thrown (due to an SO_TIMEOUT), it returns a -1
immidiately, even if the socket isn't closed.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

SSLSocket sslSock = INITIALIZE THE SSLSOCKET HERE
 
try {
  sslSock.setSoTimeout(1000); // 1 second
  InputStream ips = sslSock.getInputStream()
  while (true) {
    try {
       int b = ips.read();
       if (b==-1) {
          break; // the socket was closed
       }
    } catch(InterruptedIOException iioe) {
        // SO_TIMEOUT causes this, this is ok
    }
       
} catch(IOException e) {
   // an error occured, or the socket was closed
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
not use setSoTimeout (set the SO_TIMEOUT to 0), which
causes major problems because
read() blocks forever.
(Review ID: 163815)
======================================================================