[kaffe] Sockets remain unclosed

[Helmer Krämer]

This is a multi-part message in MIME format.

--Multipart=_Tue__6_Apr_2004_17_00_51_+0200_ghE38QvCZtkkWGZP
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue,  6 Apr 2004 20:19:11 +0900 (JST)
Ito Kazumitsu <ito.kazumitsu@hitachi-cable.co.jp> wrote:

> 
> In message "[kaffe] Sockets remain unclosed"
>     on 04/03/17, Ito Kazumitsu <ito.kazumitsu@hitachi-cable.co.jp> 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

--Multipart=_Tue__6_Apr_2004_17_00_51_+0200_ghE38QvCZtkkWGZP
Content-Type: application/octet-stream;
 name="socket-patch"
Content-Disposition: attachment;
 filename="socket-patch"
Content-Transfer-Encoding: base64

SW5kZXg6IGxpYnJhcmllcy9qYXZhbGliL2phdmEvbmV0L1NvY2tldC5qYXZhCj09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K
UkNTIGZpbGU6IC9jdnMva2FmZmUva2FmZmUvbGlicmFyaWVzL2phdmFsaWIvamF2YS9uZXQvU29j
a2V0LmphdmEsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMzEKZGlmZiAtdSAtcjEuMzEgU29ja2V0
LmphdmEKLS0tIGxpYnJhcmllcy9qYXZhbGliL2phdmEvbmV0L1NvY2tldC5qYXZhCTIyIE1hciAy
MDA0IDExOjI0OjUwIC0wMDAwCTEuMzEKKysrIGxpYnJhcmllcy9qYXZhbGliL2phdmEvbmV0L1Nv
Y2tldC5qYXZhCTYgQXByIDIwMDQgMTQ6NTI6NDQgLTAwMDAKQEAgLTgyLDExICs4Miw2IEBACiAg
IHByaXZhdGUgU29ja2V0SW1wbCBpbXBsOwogCiAgIC8qKgotICAgKiBUcnVlIGlmIHNvY2tldCBp
bXBsZW1lbnRhdGlvbiB3YXMgY3JlYXRlZCBieSBjYWxsaW5nIHRoZWlyIGNyZWF0ZSgpIG1ldGhv
ZC4KLSAgICovCi0gIHByaXZhdGUgYm9vbGVhbiBpbXBsQ3JlYXRlZDsKLQotICAvKioKICAgICog
VHJ1ZSBpZiB0aGUgc29ja2V0IGlzIGJvdW5kLgogICAgKi8KICAgcHJpdmF0ZSBib29sZWFuIGJv
dW5kOwpAQCAtMzEyLDE5ICszMDcsNiBAQAogICBTb2NrZXRJbXBsIGdldEltcGwoKQogICAgIHRo
cm93cyBTb2NrZXRFeGNlcHRpb24KICAgewotICAgIHRyeQotICAgICAgewotCWlmICghaW1wbENy
ZWF0ZWQpCi0JICB7Ci0JICAgIGltcGwuY3JlYXRlKHRydWUpOwotCSAgICBpbXBsQ3JlYXRlZCA9
IHRydWU7Ci0JICB9Ci0gICAgICB9Ci0gICAgY2F0Y2ggKElPRXhjZXB0aW9uIGUpCi0gICAgICB7
Ci0JdGhyb3cgbmV3IFNvY2tldEV4Y2VwdGlvbihlLmdldE1lc3NhZ2UoKSk7Ci0gICAgICB9Ci0K
ICAgICByZXR1cm4gaW1wbDsKICAgfQogCkBAIC0zNTgsNiArMzQwLDcgQEAKICAgICAvLyBiaW5k
IHRvIGFkZHJlc3MvcG9ydAogICAgIHRyeQogICAgICAgeworICAgICAgICBnZXRJbXBsKCkuY3Jl
YXRlICh0cnVlKTsKICAgICAgICAgZ2V0SW1wbCgpLmJpbmQgKHRtcC5nZXRBZGRyZXNzKCksIHRt
cC5nZXRQb3J0KCkpOwogCWJvdW5kID0gdHJ1ZTsKICAgICAgIH0K

--Multipart=_Tue__6_Apr_2004_17_00_51_+0200_ghE38QvCZtkkWGZP--