On 22 October 2007 at 14:00, Mark Hindess <[EMAIL PROTECTED]> wrote: > > On 22 October 2007 at 15:02, "Sergey Dmitriev" <[EMAIL PROTECTED]> > 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. >
