[
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.
