harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: HARMONY-4990 [classlib][nio] file descriptors leak while work with connections
Date Mon, 22 Oct 2007 13:14:19 GMT

On 22 October 2007 at 14:00, Mark Hindess <mark.hindess@googlemail.com> wrote:
> On 22 October 2007 at 15:02, "Sergey Dmitriev" <sergey.v.dmitriev@gmail.com> 
> wrote:
> > Hello
> > 
> > I'd like to bring your attention to the Harmony issue I discovered
> > recently. As it turned out a simple server which is based on nio
> > channels cannot work (accepting and closing rapid connection)
> > long enough. The system just does out of file descriptors. See
> > HARMONY-4990.
> >
> > This issue is serious in the degree that applications of server type
> > (which uses nio/nio.channels) just can be up 5 minutes only. :) For
> > example, to be more concrete, in case of SPECjAppServer2004 (on OC4J)
> > Harmony just cannot run long enough time. It would be cool if someone
> > could take a look at nio (nio.channels?) since despite Harmony can
> > show some score on SPECjAppServer2004 it cannot "hold" it to fulfill
> > the Run&Reporting Rules - 1 hour of steady state. Harmony's time much
> > shorter.
> The problem seems to be the socket created in the java.net.ServerSocket

I mean the java.nio.channels.ServerSocketChannel.  (I was in the middle
of writing a test for the java.net code when I wrote this email and
forgot to switch context.  Incidentally, the java.net code path does not
lose file descriptors.)


> accept method.  This socket create results in a new OS socket being
> created.  However, the accept system call implicitly creates a the new
> socket itself.  The file descriptor in the socket created in the accept
> method is overwritten by the real one created by the accept system call
> leaving the old one file descriptor unreferenced/lost.
> Regards,
> -Mark.

View raw message