This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: issue with ServerSocket::accept
- From: Bryce McKinlay <mckinlay at redhat dot com>
- To: Simon <gcj at gornall dot net>
- Cc: java at gcc dot gnu dot org
- Date: Thu, 17 Jun 2004 15:42:35 -0400
- Subject: Re: issue with ServerSocket::accept
- References: <40633001.3090605@wrx-ca.com> <408935D7.2060600@wrx-ca.com> <408E92C7.9090302@wrx-ca.com> <4098164C.7050303@wrx-ca.com> <40A16233.3060301@wrx-ca.com> <40A3BB75.9060509@wrx-ca.com> <40A3BF44.4020401@wrx-ca.com> <40A42904.4010402@redhat.com> <40D17F76.9000803@gornall.net>
Simon wrote:
I think I've just run into the same bug when trying to compile the
Apache.org XML-RPC library. Just creating a 'Webserver' (one of the
supplied classes that nicely handles XML-RPC requests) is sufficient
to cause the problem. The symptoms are that the sockets don't appear
to be being closed properly, so are hanging around, and in 20 minutes
or so, the program dies from lack of available file descriptors
(per-process limit set to 1024 on the machine). It doesn't happen with
the usual javac classes.
I've heard vague rumours of this problem with some Apache.org code
before. I have not yet seen a test case to reproduce it, however, and
I'd like to understand it better. Is it possible that the WebServer
class never calls close() on its sockets, and instead relies on the
finalizers to clean them up, or something like that? A simple
ServerSocket test case I wrote didn't have any problems with file
descriptors as long as I called close() on them when finished.
Regards
Bryce