Hey That bug seems pretty much exactly describing your problem. Can I make some assumptions, please verify them: * You only get this when running in passive mode * You get the same problem doing a connect -> STOR -> disconnect * You get the same problem doing a connect -> RETR -> disconnect
Also, and this is kind of important, your wrote in your first email that your listing returned an empty list. Is this always the case? Do you see the leak when returning a non-zero size list? Looking at the workaround, we could certainly attempt using it, but first I would like to replicate the problem so we'll know the workaround will work for us. I'm on: $ java -version java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode) $ uname -a Linux niklas-laptop 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux So, I should be affected. Would you be able to share the client test script you got? /niklas On Thu, Dec 11, 2008 at 8:51 PM, Fred Moore <fred.moor...@gmail.com> wrote: > Niklas, David, All, > > here is an update on the problem we reported... more to come as we complete > some additional tests tomorrow any HELP is welcome! > > During the last few days we kept narrowing down the debug scenario in order > to have a more precise idea of this blocking problem shape & scope. > > Here are a few findings: > > 1\ KO on Linux with Sun HotSpot J2SE 1.5.0_12 or higher > > 2\ KO on Linux with Sun HotSpot J2SE 1.6.0_xx > > 3\ OK on Linux with Sun HotSpot J2SE 1.5.0_11 > > 4\ KO on Windows with Sun HotSpot J2SE 1.5.0_15 or higher > (procexplorer is showing a growing number of "File \Device\Afd\Endpoint" > which eventually will hit the max number in Windows too) > > 5\ ?? on Windows with Sun HotSpot J2SE 1.5.0_11 (will test this tomorrow to > ensure this JVM version is as safe on Windows as it is on Linux) > > > The "too many files open" condition (or its Windows variant) is hit when we > repeat a Connect, ListNames (NLST), Disconnect in a tight loop for about 1 > hour, over FTP/S TLS/Explicit. > > Please notice that these other scenarios are OK: > > A\ Just connecting/disconnecting without issuing the NLST command > > B\ Using straight FTP connection > > > The FTPServer codebase used for the test was M2-level with still some custom > code (we had no time so far to setup a "clean" M4 env), but we still believe > that the custom code is not related with the reported problem (and it's > difficult to quickly evict it in our environment right now). > > We currently believe to have incurred in this JVM bug "SSLServerSocket file > descriptor leak": > http://bugs.sun.com/view_bug.do?bug_id=6764972 : > > ---begin--- > File descriptors of TCP sockets are not released properly when using > SSLServerSocket class ( especially with many instances ) on Linux systems. > > If a server application ( like Jakarta Tomcat ) runs very long time, > this problem will cause a 'too many open files' error and a denial of > the service. > ---end--- > > > Given your very detailed knowledge of FTPServer source code and bug 6764972 > description, do you think this might be the case? > Can you suggest any patch / workaround for that? > > Any help at this stage is highly appreciated! > Cheers, > F. > > PS: speaking of workarounds this thread may/may not be relevant for the case > at hand (look up "leak" & "layer" keywords): > http://www.nabble.com/-security-dev-00402-:-Re:-NullPointerException-at%09sun.security.ssl.OutputRecord.writeBuffer-td20492154.html >
