With Solaris green threads, if one thread is blocked in ServerSocket.accept and another thread closes that socket, there appears to be no effect on the accept call; no exception is thrown.  With Solaris native threads, the result is that the process no longer responds to shell job control (^C, ^Z, etc), it has to be killed with a kill -9 from another shell.  See the attached test program.

N/A

The native threads hang is most likely a duplicate of 4096914, which will
probably be fixed for 1.2FCS.
  xxxxx@xxxxx   1998-08-04

The original bug was against Solaris 2.5.1 which had a kernel bug which lead
to the hang. This isn't an issue with Solaris 2.6, 7, .... In addition a
workaround was put into J2SE 1.2 so that threads blocked on the socket are
interrupted prior to closing the fd.
Based on this I am closing this bug as a duplicate of 4096914.
  xxxxx@xxxxx   2000-09-19

we too have this problem with jdk1.1.3 running
on solaris 2.6. does this have a side effect on the
threads that were started by the program who called
accept ?

It's a Solaris 2.6 OS bug, #4043763.  I've seen
sevreral workarounds, but calling Thread.stop()
on the accepting thread doesn't seem to work either.
Same behavior in JDK1.1.5 and JDK1.1.6.

We have the smae problem. We would REALLY like a workaround.
Simply exiting the program without closing the socket is
a poor solution at best.

I suppose this to be bug 4096914

I could think of workaround:
use ServerSocket.setSoTimeout(1) to produce
a java.io.InterruptedIOException

Other workaround:
To make your listening thread be active again:
1. Set a state variable to tell it is in a stopping state (see
java.lang.Thread.stop() discussion)
2. Create a dummy socket and connect it to the port you're listening on to make
accept() call return and have your listening thread be active.
It's not great, but I found it easier to implement that the timeout

I have the same problem on Windows`95 (not NT). I can't ServerSocketObj.close()
after I stopped the thread which was doing ServerSocketObj.accept();

I have the same problem with Windows NT with 
java version "1.2.2"
Classic VM (build JDK-1.2.2_006, native threads, symcjit)
close() certainly should trigger an exception in the accept() method. The workaround is to use set 
SO_TIMEOUT, which is less than perfect.

I had the same problem.
The workaround was to try to create a client socket 
connetion to the server socket before trying to close it. 
In this case the accept() method returns...