Luke,
unfortunately, I cannot reproduce the problem in on my machine - I do not see any open file descriptors left over after I connect to Hunchentoot server with SSL using a non-SSL client, and when I connect to the same server using a browser, I get an "Empty response" error.
In order to help you with this, I need you to isolate the problem further. Some ideas for debugging:
- Can you create a lingering file descriptor when you connect to your server using telnet, then disconnect?
- Are the CLOSE_WAIT sockets actually connected to your monitoring service?
- Do you see the CLOSE_WAIT in lsof or in netstat? I see it in netstat for sockets that have been closed by the application, but for which the FIN TCP packet has not been acknowledged by the client. Note that CLOSE_WAIT sockets are closed in the application and do no longer consume file descriptors. The final TCP handshake is performed by the kernel, and there is nothing that Hunchentoot can do to make these sockets disappear.
I'm not saying that Hunchentoot has no bugs, but from your description, it appears to me that your problem is related to your kernel configuration (you're hitting the system-wide limit for sockets, not the process limit for file descriptors).
-Hans