John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> Ya, for your interests what I'm doing is starting a Swiki, then bring 
> up a page, then hold the refresh page command key down, this works 
> best from Netscape Unix since  it queues the keystrokes. This 
> generates 100's of HTTP connections. Some of which timeout and the 
> browser closes the socket in the middle of connection. Do this for a 
> few minutes, observe 100's of Sockets waiting to be finalized. Do a 
> full GC or wait awhile. Examine macintosh Squeak TCP/IP structures, 
> see a couple of sockets in error state, but also *NOT* processed by 
> destroy. Wonder why no instances of sockets in image, but 8 socket 
> handles still allocated, they won't be destroyed now since the image 
> does't have a reference to them anymore. Quit Squeak, paranoid 
> cleanup logic hunts down and closes the 8 sockets.
> 


Wonderful test!  FWIW, I tried it with Squeak 2.8alpha (slightly old)
and Com45Swiki9 on Linux.  I did get quite a large number of debugger
windows and a few hundred open sockets, but:

	1. The final request to the server did succeed.

	2. After closing all the debuggers and doing a "space left", all the
open sockets went away.

Closing the debuggers alone did *not* do the trick, so it looks like
GC+finalization did close a lot of those sockets.  (Also, it's too bad
this scenario brings up debuggers, but that's a separate problem).

It's a sneaky bug, eh?


> Of course the original issue was why does a Swiki locking up under 
> load/ or after a long period of time.
> 

Hmm, if the OS runs out of sockets, certainly nasty things will happen. 
It would even make sense for the server to keep responding
to mouse and keyboard interaction -- at least some versions of
Comanche are smart enough not to busy-loop at high priority
if there is a shortage of sockets.


-Lex