On Fri, Mar 26, 2010 at 9:50 AM, Fred Moore <fred.moor...@gmail.com> wrote: > 1\ Priority of passive port sharing ehnancement: Niklas survey shows that we > are indeed in good company here, but it's problably worth having a better > look at this anyway, there might be good technical reasons that led all the > other teams not to support this or it may turn up that it's "simply" because > it's somewhat hard to develop and test.
After this discussion I'm significantly less thrilled at implementing shared passive ports :-) > 2\ Quick fix for 1.0.x codebase: pushing a 40x to the client when no > passive port is available (or probably better: no passive port is available > within X seconds) it's probably something we need to do anyway. Thinking some more about this, I'm personally now convinced that should simple return an error (not waiting). I'm not sure what the best reply code should be, but "425 Can't open data connection" seems fitting although not specified as valid return from the PASV command. > 3\ Suspect race condition: the problem description for the originally > reported http://issues.apache.org/jira/browse/FTPSERVER-359 (see also repro > code attached to the jira) actually hints also to something different as > well, in fact we state that a few (say 20) parallel threads issuing LISTs in > passive mode are able to "lock-up" the server forever. Questions: > > 3.1\ Is this interely explained by this thread discussion? (I don't think > so: the server should *always* be able to recover) Agreed, the server should always recover from a situation like this. After looking into how to fix item 2, we need to rerun your tests and make sure we always survive. > 3.2\ Would this be fixed by a quick fix as per 2\? (likely, but it's sort of > like using nukes to for mowing the lawn) I really have no idea, but I think we should fix 2 first and then make sure we handle your test case. > In short my current position can be stated as follows: I think that > FTPSERVER-359 has a different root cause from what we discussed, the problem > impact is not completely known at the moment but it appears to *severely* > affect the server availabily... having just one port is an easy way of > reproducing it (but not the cause of it). Agreed. /niklas
