You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Dheeraj (JIRA)" <ji...@apache.org> on 2012/11/26 10:26:58 UTC
[jira] [Commented] (NET-46) [net] retrieveFileStream fails randomly
[ 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 [~anders@nufort.net]:
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