On Tue, 6 Apr 2004 20:19:11 +0900 (JST) Ito Kazumitsu <[EMAIL PROTECTED]> wrote:
> > In message "[kaffe] Sockets remain unclosed" > on 04/03/17, Ito Kazumitsu <[EMAIL PROTECTED]> writes: > > > Summary: > > > > When you use Jetty with Kaffe, the number of idle sockets > > gradually increases until "too many open files" error may occur. > > The value of Jetty's parameter MaxIdleTimeMs is 10000 ms by default, > > so a new socket is created and thrown away in every 10 seconds. > > Setting MaxIdleTimeMs to a reasonable value will slow down the > > the creation of new sockets and you can avoid "too many open files". > > > > That was not a complete solution. Although the creation of new sockets > > can be slowed down, the number of sockets still increases gradually. > > > > I patched java/net/ServerSocket.java to see if this problem can be > > solved. The result is satisfactory. > > Unfortunately, this is not the end of the story. > > With the patch to java/net/ServerSocket.java, Jetty works almost > fine. But the number of open sockets still increases slowly but > steadily and in a long run, "too many open files" error will happen. > > The problem is: > > (1) When accept() is done, two file descriptors are generated. > (2) When the socket is closed, one of the two file descriptors is > closed but the other remains unclosed. > > The problem may be OS-dependent and my OS is Linux 2.4.18-3. Looks like a bug in java.net.Socket.... java.net.ServerSocket.accept() eventually calls impl.accept (socket.getImpl()), where "socket" is the java.net.Socket instance returned by the accept() call. java.net.Socket.getImpl() however calls impl.create(), which opens the new fd that never gets closed, since all references to it get overwritten in the impl.accept() call. Easiest way to fix this might be something like the attached patch. Regards, Helmer
socket-patch
Description: Binary data
