commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dheeraj (JIRA)" <>
Subject [jira] [Commented] (NET-46) [net] retrieveFileStream fails randomly
Date Mon, 26 Nov 2012 09:26:58 GMT


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 []:	recvfromBytes	-2	true	recvfrom	131	false	recvfrom	164	false	recvfrom	513	false	read	488	false	access$000	46	false$PlainSocketInputStream	read	240	false	read	244	false	fillBuf	130	false	read	238	false	readLine	58	false	__getReply	310	false	__getReply	290	false	sendCommand	479	false	_openDataConnection_	769	false	_retrieveFileStream	1747	false	retrieveFileStream	1739	false	

My guess is that in __openDataConnection__(), the following line to set the dataTimeOut should
have been set *before* calling sendCommand():

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

View raw message