Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.0.4
-
None
-
None
-
windows
Description
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)