[
https://issues.apache.org/jira/browse/NET-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503691#comment-13503691
]
Dheeraj commented on NET-46:
----------------------------
I faced a similar hang in retrieveFileStream() when using commons-net-3.1. And
the callstack is essentially similar to that posted by [[email protected]]:
libcore.io.Posix recvfromBytes Posix.java -2 true
libcore.io.Posix recvfrom Posix.java 131 false
libcore.io.BlockGuardOs recvfrom BlockGuardOs.java 164 false
libcore.io.IoBridge recvfrom IoBridge.java 513 false
java.net.PlainSocketImpl read PlainSocketImpl.java 488 false
java.net.PlainSocketImpl access$000 PlainSocketImpl.java 46
false
java.net.PlainSocketImpl$PlainSocketInputStream read PlainSocketImpl.java
240 false
java.io.InputStreamReader read InputStreamReader.java 244 false
java.io.BufferedReader fillBuf BufferedReader.java 130 false
java.io.BufferedReader read BufferedReader.java 238 false
org.apache.commons.net.io.CRLFLineReader readLine
CRLFLineReader.java 58 false
org.apache.commons.net.ftp.FTP __getReply FTP.java 310 false
org.apache.commons.net.ftp.FTP __getReply FTP.java 290 false
org.apache.commons.net.ftp.FTP sendCommand FTP.java 479 false
org.apache.commons.net.ftp.FTPClient _openDataConnection_ FTPClient.java
769 false
org.apache.commons.net.ftp.FTPClient _retrieveFileStream FTPClient.java
1747 false
org.apache.commons.net.ftp.FTPClient retrieveFileStream FTPClient.java
1739 false
My guess is that in __openDataConnection__(), the following line to set the
dataTimeOut should have been set *before* calling sendCommand():
socket.setSoTimeout(__dataTimeout);
Otherwise, the client would be waiting indefinitely for the server's reply to
the RETR command.
FWIW, I'm running it on Android 4.x
> [net] retrieveFileStream fails randomly
> ---------------------------------------
>
> Key: NET-46
> URL: https://issues.apache.org/jira/browse/NET-46
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 1.4
> Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Dennis Meerveld
>
> For my application I need a way to get the InputStream of a binary file on a
> FTPServer. What I did was :
> // connect and get ftpFiles as an array
> // for each ftpFile ...
> InputStream is = ftp.retrieveFileStream(ftpFiles[i].getName());
> However, this behaves erratically : sometimes the inputstream is correct and
> sometimes it is null (and the ftpFile exists, no weird name or anything odd
> about it).
> After first blaming my FTPServer (I use GuildFTPd 0.9.9.13) I tried another
> FTPServer (Serv-U 6.1), but this also had the same behavior.
> Then I thought I might have to do with timing. So I tried Thread.sleep(xxx)
> on a
> couple of locations but to no avail. In a last attempt (was getting pretty
> desperate :) ) I rewrote my original line and replaced it by this :
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> ftp.retrieveFile(ftpFiles[i].getName(),out);
> InputStream is = new ByteArrayInputStream(out.toByteArray());
> And much to my surprise, it worked like a charm. Tested it a couple of times
> (on
> both FTPServer products) and works perfectly.
> So I'm guessing something is going wrong in your retrieveFileStream
> implementation. Maybe something worth looking into ? (easiest fix : use the
> ByteArrayOut/InputStream swap :)).
> kind regards,
> Dennis
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
