Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 26 Nov 2012 09:26:58 +0000 (UTC)
From: "Dheeraj (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <1002082739.22335.1353922018674.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (NET-46) [net] retrieveFileStream fails randomly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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