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