Just so we are all on the same page - Do you think the issue is with the LIST command, or the code that creates passive data connection? Could you briefly explain some of the issues that made you think it should be rewritten, so everyone gets a chance to evaluate?
Thanks. Regards, Sai Pullabhotla On Thu, Mar 25, 2010 at 5:56 AM, David Latorre <[email protected]> wrote: > 2010/3/24 Niklas Gustavsson <[email protected]>: >> On Wed, Mar 24, 2010 at 6:03 PM, Fred Moore <[email protected]> wrote: >>> we found an issue related to requestPassivePort() which may lead to an >>> unresponsive V1.0.4 FTP (or FTP/S) Server, this issue can be reproduced. >>> >>> http://issues.apache.org/jira/browse/FTPSERVER-359 contains full description >>> of the symptoms and a minimalist java client and server to reproduce it. >> >> I haven't yet looked closer at the code you attached. But, I have seen >> similar behavior myself during performance testing FtpServer. In that >> case, I had a very similar behavior at around 20 threads. However, the >> reason for the problem in that test was that the test case uses up >> file handles (for the sockets) so fast that they will run out. Since >> sockets hang around for some time also after closing, they were not >> freed quickly enough and thus FtpServer could not open new ones. Could >> you please verify that this is not the case here? You could look at >> netstat output and look into increasing the allowed number of file >> handles our the timeout time for sockets in your OS. > > > Actually it is quite easy to reproduce this error (I just wrote a > client test case with throws >20~30 threads that list a directory in > the server ) and it's not file handle related: > we have several bugs in our code that cause this behaviour , i > think we hould rewrite all the request/release passive port mechanism > as there are several issues with it. > > > > > > > >> /niklas >> >
