Hey, Fred you should try the workaround proposed in security-dev:
In JSSE, you can layer a SSLSocket over an existing Socket. That will avoid SSLServerSocket creating the dummy Socket that is eventually leaking the file descriptors. ServerSocket ss = new ServerSocket(port); > Socket s = ss.accept(); > sslssf.createSocket(s, s.getInetAddress().getHostName(), > s.getPort(), false); and see if this solves your issue. The simplest thing I can think of is that you try the provided test case and then the proposed workaround. If this solves your issue, we might want to implement this as the standard mechanism to create SSLServerSockets as the JVM creates "dummy" sockets anyway. 2008/12/11 Niklas Gustavsson <nik...@protocol7.com> > 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 > > >
