[jira] Updated: (FTPSERVER-359) Race condition during requestPassivePort() hanging FTP(S) server with one passive data connection port

["Fred Moore (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FTPSERVER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fred Moore updated FTPSERVER-359:
---------------------------------

    Attachment: FTPSERVER-359-ReproSrcAndCfg.zip

repro source & config

> Race condition during requestPassivePort() hanging FTP(S) server with one passive data connection port
> ------------------------------------------------------------------------------------------------------
>
>                 Key: FTPSERVER-359
>                 URL: https://issues.apache.org/jira/browse/FTPSERVER-359
>             Project: FtpServer
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 1.0.4
>         Environment: windows
>            Reporter: Fred Moore
>         Attachments: FTPSERVER-359-ReproSrcAndCfg.zip
>
>
> We have various situations where FTP(S) server is used with a limited range of Passive Ports available for connection (in some cases the range restricts to just ONE port). 
> This configuration has been tested and it works with the normal drawback that users requesting simultaneous file transfers are queued but they can be still connected at the same time.
> However it clearly appears that there are some race conditions when multiple clients attempt to open simultaneously passive connections. In such case, instead of queueing up and slowly serve them up, the server is "forgetting" to notify properly the fact that Passive Ports are progressively freed effectively hanging up for ever the server which is not allowed to serve further connections unless killed and restarted.
> A repro of this unlucky situation can be easily obtained launching the attached EmptyServer.java with an aggressive 20-thread client (TestShortTimeOut.java).
> Each concurrent thread is simply connecting, logging-in as anonymous and listing a directory with 3 files (NO actual file transfer is done, just lookups), and then quitting and disconnecting. 
> This test produces on my Windows XP machine almost instantly the following exception:
> connected thread 5
> Listed files #3 for thread 0
> Disconnected thread 0
> java.net.SocketTimeoutException: Read timed out
> Exception on thread 4 Read timed out
>      at java.net.SocketInputStream.socketRead0(Native Method)
>      at java.net.SocketInputStream.read(Unknown Source)
>      at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
>      at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
>      at sun.nio.cs.StreamDecoder.read(Unknown Source)
>      at java.io.InputStreamReader.read(Unknown Source)
> And the server is left in an inconsistent state not accepting further connections.
> They have been tested with current distributed FTPServer 1.0.4 version and commons net. Launching EmptyServer provides a server with a singleton port range (port 1024). 
> Launching the TestShortTimeOut.java produces very quickly a situation where the server is hung with all the threads waiting to get a requestPassivePort() even if no client is still attached since all threads are quitting for timeout (in the client I put the timeout to 2 seconds to have quickly this situation, but nothing essentially changes when timeout is not set and so is the default. 
> If it can be of any help, attached you can find the log4j debug trace.(test.log). Which might give some light to FTPServer gurus. 
> NOTE.
> I originally found this problem with the FTPS implementation, but was able to reproduce the same problem even with simpler standard FTP (you can see that Empty Server is actually acting as a FTPS server and the client has still commented the FTPS client commands).
> I tried to use the minimal level of concurrency that is producing the
> RACE condition on my machine. If I use less than 15-16 threads the
> server appears behaving correctly, but with 20 threads it surely breaks down.
> PS.
> I have analyzed all problems present in FTPServer JIRA related to connected problems and passive ports and I've found the following:
> 1\ FTPServer-293 hang while transferring file (not our case since we are
> just listing and the patch is already on the distributed version),
> 2\ FTPServer-303 and FTPServer-177 seems related but already distributed
> 3\ FTPServer-240 which is still NOT been distributed and might solve (!) my
> problems since allows for serving multiple clients with a limited range
> of passive ports... even if it probably does not really fix the actual root cause (suspect race condition)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.