You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2007/10/22 15:00:51 UTC

Re: HARMONY-4990 [classlib][nio] file descriptors leak while work with connections

On 22 October 2007 at 15:02, "Sergey Dmitriev" <se...@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
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.



Re: HARMONY-4990 [classlib][nio] file descriptors leak while work with connections

Posted by Mark Hindess <ma...@googlemail.com>.
On 22 October 2007 at 14:00, Mark Hindess <ma...@googlemail.com> wrote:
> 
> On 22 October 2007 at 15:02, "Sergey Dmitriev" <se...@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.)

-Mark.

> 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.
>