when upload big file(11g db backup file), timed out trying to read data from the socket stream! #387
Comments
|
**FTP Server: Synology NAS (DSM 6.2.1-23824 Update 6) **Filesize: 730MB I have the same problem. The upload is completed correctly and the file is valid. |
|
Try this and tell me if it works:
|
|
change to DataConnectionType = FtpDataConnectionType.EPSV, still same problem |
|
**FTP Server: Filezilla Server on Windows Server 2016 **Filesize: 17GB I have the same problem. The upload is completed correctly and the file is valid but thrown an exception:
|
|
I migrated my code from
Here are the code comments for
The log in the original post indicated that the client connected using Someone indicated that updating their FileZilla server resolved the issue. Thank you. Edit I also tried setting |
|
I'm having the exact same problem. File size I am trying to download is 4.3GB. After the file has been downloaded entirely, I get an exception: FluentFTP.FtpException: Error while downloading the file from the server. See InnerException for more info. ---> System.TimeoutException: Timed out trying to read data from the socket stream! I tried doubling the ReadTimeout and DataConnectionReadTimeout initially before realizing the file was downloading entirely before the exception. Like @icnocop I migrated to FluentFTP from System.Net.FtpWebRequest thinking the issue would resolve but then found this thread. Anyone find any fixes to this? Edit: I should note, I am able to download the file using FileZilla and CuteFTP without issue. |
|
I solved it this way... int progress = -1;
try
{
FtpClient client = new FtpClient("HOST");
client.Credentials = new NetworkCredential("USER", "PASSWORD");
client.Connect();
client.UploadFile("LOCALPATH/FILENAME", "REMOTEPATH/FILENAME",
FtpExists.Overwrite,
false,
FtpVerify.None,
new Progress<FtpProgress>(p => progress = Convert.ToInt32(p.Progress))
);
}
catch (Exception ex)
{
if (progress == 100 && ex is FluentFTP.FtpException && ex.InnerException != null && ex.InnerException is TimeoutException)
{
// Upload complete
// LOG Info exception
}
else
{
// LOG Fatal exception
throw;
}
} |
|
The @stefanolazzarato has been working up until today. Downloaded an 11,525 KB file and got a System.OverflowException on converting the progress value to an Int32 in production. Haven't been able to debug it - did look at the FluentFTP ReportProgress function looks like it is doing a progressValue = (double) position / (double) fileSize * 100; Likely bad values are getting in - going to try to make the progress variable a double and check for >= 100 on exception instead. |
|
@stefanolazzarato thanks for this fix, I finally understood the problem! I've attempted to absorb all TimeoutExceptions during upload/download if the file is fully transferred in the latest version https://www.nuget.org/packages/FluentFTP/27.1.4 @stefanolazzarato @wjchristenson2 @icnocop @nicojmb @luchunminglu |
|
@robinrodricks I updated my project to the new version. I'll try it in the next days. |
|
Thank you, @robinrodricks. I updated to FluentFTP 27.1.4 but I still get a TimeoutException when downloading a 3.43 GB file. When the exception is thrown, progress is at 100%, so I'm able to use @stefanolazzarato's workaround. Here's the stack trace: |
|
@icnocop Please try the latest release, it should be fixed now.. |
|
Still exist |
|
Greetings. Testing 28.0.1 at console app (package added via Nuget). |
|
Test finished:
Sorry, the problem about TimeoutException still exists :( @robinrodricks |
|
@SETSinsperion, can you provide a stack trace? |
|
@icnocop of course, but I'm sorry, I closed the project having in mind that your answer will be later. I will test again and I provide my stack trace.. |
|
@icnocop @robinrodricks Test finished: I have a upload method inside a .dll created for me, the first StackTrace is the Main method which I call the upload method. The 2nd Stacktrace is the main interest: StackTrace1. In Main.cs
2. This exception has an InnerException that is the StackTrace that throws upload method:
InnerException 1: InnerException 2: Code:Main.cs Upload method: I hope this will guide to a solution. |
|
Hi. I updated to FluentFTP 28.0.2 from NuGet. I downloaded a 3.46 GB file, but still received the same exception: Thank you. |
|
Hi, I am using version 28.0.5. Same timeout exception still occurs when downloading. In my case, file size is approximately 400MB. Sometimes the download times out at 99%, sometimes at 100%. Download gets to 99% hangs for the duration of timeout (15 sec in this case - default timeout) and throws TimeoutException. I find his quite interesting, because I actually started using FluentFTP to get rid of this exact problem. At first, I wrote a basic downloader using WebClient and it experienced very similar behavior. File download got to 99% or 100% and then stopped, doing nothing, until it eventually timed out. I was not able to fix it, so I worked around it by using Polly and just re-tried the download request when timeout expired. I recently heard about FluentFTP and I thought it might be able to fix the issue, so I gave it a shot, but with the same results. Code and logs below: My code: Logs: I hope this will get fixed soon, but in the meantime I went back to retrying via Polly. Maybe someone'll find this useful as a temporary workaround: FtpClient is configured to append to an existing file (FtpLocalExists.Append). After Polly executes a retry, second call to server will detect that the file on the disk is the same size as the one on the server (even though the ProgressCallback got stuck at 99%). This will result in a graceful termination and the download will finish: |
|
Experiencing same problem with v28.0.5 when uploading files larger than ~460,000,000 bytes (or that takes longer than ~280), hangs on completion throwing TimeoutException. FluentFTP client runs in Azure VM, server runs IIS outside of Azure. Reproduces every time. Details below. Successfully working around by setting The
using (var client = new FluentFTP.FtpClient()
{
Host = host,
Port = port,
Credentials = new NetworkCredential(username, password),
//
ConnectTimeout = 3000, // tried 3..120s
ReadTimeout = 3000, // tried 3..120s
DataConnectionConnectTimeout = 3000, // tried 3..120s
DataConnectionReadTimeout = 3000, // tried 3..120s
DataConnectionType = FtpDataConnectionType.AutoPassive,
SocketKeepAlive = true,
SocketPollInterval = 1000, // makes no difference
EnableThreadSafeDataConnections = false // true works around the problem
})
using (var stream = File.OpenRead(file))
{
Console.Write("Connecting...");
client.Connect();
Console.Write("Changing directory...");
client.SetWorkingDirectory(path);
Console.Write("Uploading...");
client.Upload(stream, Path.GetFileName(file));
Console.Write("Disconnecting...");
client.Disconnect();
}Running client in AzureVM, throws after ~290 seconds when upload has completed; On my laptop instead of Azure VM the client upload successfully runs in 100 seconds instead of 290 seconds; Finally running in AzureVM with workaround, |
… alive during file transfers
|
@robinrodricks created a pull request tested successfully with uploading large file There are opinions about sending NOOP during file transfer, but bottom-line is that it solves these types of problems; Please note that I fired the code for downloading from the hip, just more of the same as for uploading that I have verified (trace below). using (var client = new FluentFTP.FtpClient()
{
Host = host,
Port = port,
Credentials = new NetworkCredential(username, password),
//
ConnectTimeout = 3000,
ReadTimeout = 3000,
DataConnectionConnectTimeout = 3000,
DataConnectionReadTimeout = 3000,
DataConnectionType = FtpDataConnectionType.AutoPassive,
SocketKeepAlive = true,
SocketPollInterval = 15000,
EnableThreadSafeDataConnections = false,
NoopInterval = 15000, //<<<<<<<<<<<<<<<<<<<<<<<< Send NOOP every 15 seconds
})
using (var stream = File.OpenRead(file))
{
Console.Write("Connecting...");
client.Connect();
Console.Write("Changing directory...");
client.SetWorkingDirectory(path);
Console.Write("Uploading...");
client.Upload(stream, Path.GetFileName(file));
Console.Write("Disconnecting...");
client.Disconnect();
}Edit; fixed the logging so it says |
|
Tested successfully also the Download operation; using (var client = new FluentFTP.FtpClient()
{
Host = host,
Port = port,
Credentials = new NetworkCredential(username, password),
//
ConnectTimeout = 3000,
ReadTimeout = 3000,
DataConnectionConnectTimeout = 3000,
DataConnectionReadTimeout = 3000,
DataConnectionType = FtpDataConnectionType.AutoPassive,
SocketKeepAlive = true,
SocketPollInterval = 15000,
EnableThreadSafeDataConnections = false,
NoopInterval = 15000,
})
using (var stream = File.OpenWrite(file))
{
Console.Write("Connecting...");
client.Connect();
Console.Write("Downloading...");
client.Download(stream, path);
Console.Write("Disconnecting...");
client.Disconnect();
} |
|
Thanks a ton @aliquid for fixing this long standing issue. Gone live with 29.0.0. @luchunminglu @SETSinsperion @icnocop @stefanolazzarato @wjchristenson2 All are suggested to grab the latest version and see if it solves their problem: https://www.nuget.org/packages/FluentFTP/29.0.0 If you still see errors, decrease the |
robinrodricks
added
work in progress
fixed
and removed
fixed
duplicate
work in progress
labels
|
Thnx @robinrodricks !! Successfully tested Upload and Download operations with 29.0.0 from our AzureVM environment, transferring 486MB file 290s up 110s down. We integrate with a large number of completely different FTP servers, all behaving differently, so the configurable nature of FluentFTP is what makes it so great for us. For years we have been sending files a couple of KB up to 200 MB, but recently we started sending some odd files close to 300 MB to one of our endponts when problems started for us. It seems that the AzureVM router or firewall does not respect TCP Keep-Alive on the control socket (port 21). When large file transfers runs on data socket (20 or passive) there is no traffic on the control socket and it breaks for us after ~280s (perhaps 240s). Before mentioned workaround setting The NOOP command responds something like '200 NOOP command successful.' and is typically used by a FTP UI client to keep the control socket alive in-between commands, so it is a good candidate for using also during long-running command executios (i.e. RETR/STOR). However the https://tools.ietf.org/html/rfc959 neither suggests that nor against it. Indeed, googling shows that it has been proven in battle, with some odd complaints (see link to smartftp.com some comments back) that it could potentially cause file transfers to abort (remains to be proven) or make FTP servers behave strangely like not responding 200 (that is what I can see from IIS) or respond at the end of the file transfer (have no such evidence, but pull request attempted to cope with that in a rudimentary manner). Suggested usage for
|
Writing above got me thinking, adding below to just before the break in This is theory as I have no evidence for it. I cannot experiment with all our endpoints to see if any would be responding at all to NOOPs during file transfers, only with our internal which runs IIS. Perhaps others reading could help provide evidence one way or the other by uploading/downloading two files consequtively with Just wanted to get this concern off my chest. while (!m_threadSafeDataChannels) {
... existing code up to here stands fine imo ...
// Fix #387: exhaust any NOOP responses also after "226 Transfer complete."
if (anyNoop)
ReadStaleData(false, true, true); // await ReadStaleDataAsync(..., token);
break;
} |
|
Hi, could you please pull the latest source and submit a PR? If you can't
I'll go thru your snippet and try to integrate it, but you're the expert
here so you may be far better at ensuring I don't break the logic!
…On Mon, Jan 6, 2020, 6:43 PM aliquid ***@***.***> wrote:
... or respond at the end of the file transfer (have no such evidence, but
pull request attempted to cope with that in a rudimentary manner).
Writing above got me thinking, adding below to just before the break in
Upload/DownloadFileInternal/Async would make coping with NOOP responses
less rudimentary and more robust by exhausting them not only before the
"226 Transfer complete." but also after it (as should be the case, as
specified by "4.2 FTP REPLIES" in the RFC 959
<https://tools.ietf.org/html/rfc959>). Of course Execute() can do that
(if StaleDataCheck = true) with its ReadStaleData(true, ..), but with the
side-effect of dropping the connection and opening a new.
This is theory as I have no evidence for it. I cannot experiment with all
our endpoints to see if any would be responding at all to NOOPs during file
transfers, only with our internal which runs IIS. Perhaps others reading
could help provide evidence one way or the other by uploading/downloading
two files consequtively with NoopInterval configured to see if it
triggers with StaleDataCheck = true? I tested multiple consecutive
uploads and downloads but with IIS there are no NOOP responses during file
transfer so existing code stands file.
Just wanted to get this concern off my chest.
while (!m_threadSafeDataChannels) {
... existing code up to here stands fine imo ...
// Fix #387: exhaust any NOOP responses also after "226 Transfer complete."
if (anyNoop)
ReadStaleData(false, true, true); // await ReadStaleDataAsync(..., token);
break;
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#387?email_source=notifications&email_token=ABT3UKXNH5VYSCHO7CTPKETQ4MU6JA5CNFSM4HBTL4BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIFMYZQ#issuecomment-571133030>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABT3UKTBP2KVL6PB7HTB36LQ4MU6JANCNFSM4HBTL4BA>
.
|
|
No problem. Below from my testing but again it shows no evidence the added code does anything. Uploading, with IIS no sign of stale data after Downloading, with IIS no sign of stale data after |
#387 exhaust NOOP responses also after 226 Transfer complete
|
Unfortunately I'm getting an exception when trying to download a large file using FluentFTP 29.0.1 with these settings: Exception: The file is about 3.5 GB. Any ideas? Thank you. |
|
Keep the default noop interval.
…On Fri, Jan 17, 2020, 6:03 AM Rami ***@***.***> wrote:
Unfortunately I'm getting an exception when trying to download a large
file using FluentFTP 29.0.1 with these settings:
client.SocketKeepAlive = true;
client.SocketPollInterval = 15000;
client.EnableThreadSafeDataConnections = false;
client.NoopInterval = 15000;
Exception:
FluentFTP.FtpException: Error while downloading the file from the server. See InnerException for more info. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at FluentFTP.FtpExtensions.IsKnownError(String reply, String[] strings)
at FluentFTP.FtpClient.GetFileSizeInternal(String path, FtpSizeReply sizeReply)
at FluentFTP.FtpClient.GetFileSize(String path)
at FluentFTP.FtpClient.OpenRead(String path, FtpDataType type, Int64 restart, Boolean checkIfFileExists)
at FluentFTP.FtpClient.OpenRead(String path, FtpDataType type, Int64 restart)
at FluentFTP.FtpClient.ResumeDownload(String remotePath, Stream& downStream, Int64 offset, IOException ex)
at FluentFTP.FtpClient.DownloadFileInternal(String remotePath, Stream outStream, Int64 restartPosition, Action`1 progress)
--- End of inner exception stack trace ---
at FluentFTP.FtpClient.DownloadFileInternal(String remotePath, Stream outStream, Int64 restartPosition, Action`1 progress)
at FluentFTP.FtpClient.DownloadFileToFile(String localPath, String remotePath, FtpLocalExists existsMode, FtpVerify verifyOptions, Action`1 progress)
at FluentFTP.FtpClient.DownloadFile(String localPath, String remotePath, FtpLocalExists existsMode, FtpVerify verifyOptions, Action`1 progress)
The file is about 3.5 GB.
The exception occurs after about 8 minutes.
At the time of the exception, the progress of the download is about 15%.
Any ideas?
Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#387?email_source=notifications&email_token=ABT3UKVEYSNXIR3R2THZT6TQ6D4D5A5CNFSM4HBTL4BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJGBMVA#issuecomment-575411796>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABT3UKV44V7UOOIRTEU3D2TQ6D4D5ANCNFSM4HBTL4BA>
.
|
|
Thank you. Unfortunately I'm still getting the TimeoutException when downloading a large file using FluentFTP 29.0.1 with these settings: At the time of the exception, the progress of the download is 100%. |
|
@robinrodricks, that worked! 🎉 FluentFTP 29.0.3 no longer throws a TimeoutException when downloading a large file (3.53 GB). Thank you very much! 😃 |
**FTP OS: winserver2016
**FTP Server:filezilla0.9.60
**Computer OS:winserver 2012
it doesn't happen when upload small file.
when upload a big（test on 200mb & 10gb） db backup file, client.UploadFile(localFullFilePath, ftpFullPath) method report a timeout exception.The Error is "Timed out trying to read data from the socket stream! "
the wield thing is the db file is actual uploaded, i check the file size in ftp is right(but not check the file content).
so i think may be after upload big file, the flutent ftp does something read, which cause this error.
FluentFTP.FtpException: Error while uploading the file to the server. See InnerException for more info. ---> System.TimeoutException: Timed out trying to read data from the socket stream!
在 FluentFTP.FtpSocketStream.Read(Byte[] buffer, Int32 offset, Int32 count)
在 FluentFTP.FtpSocketStream.ReadLine(Encoding encoding)
在 FluentFTP.FtpClient.GetReply()
在 FluentFTP.FtpClient.UploadFileInternal(Stream fileData, String remotePath, Boolean createRemoteDir, FtpExists existsMode, Boolean fileExists, Boolean fileExistsKnown, IProgress
1 progress) --- 内部异常堆栈跟踪的结尾 --- 在 FluentFTP.FtpClient.UploadFileInternal(Stream fileData, String remotePath, Boolean createRemoteDir, FtpExists existsMode, Boolean fileExists, Boolean fileExistsKnown, IProgress1 progress)在 FluentFTP.FtpClient.UploadFileFromFile(String localPath, String remotePath, Boolean createRemoteDir, FtpExists existsMode, Boolean fileExists, Boolean fileExistsKnown, FtpVerify verifyOptions, IProgress
1 progress) 在 FluentFTP.FtpClient.UploadFile(String localPath, String remotePath, FtpExists existsMode, Boolean createRemoteDir, FtpVerify verifyOptions, IProgress1 progress)(000001)2019/3/28 12:50:03 - scims (192.168.163.1)> OPTS UTF8 ON
(000001)2019/3/28 12:50:03 - scims (192.168.163.1)> 202 UTF8 mode is always enabled. No need to send this command.
(000001)2019/3/28 12:50:03 - scims (192.168.163.1)> SYST
(000001)2019/3/28 12:50:03 - scims (192.168.163.1)> 215 UNIX emulated by FileZilla
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> PWD
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> 257 "/" is current directory.
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> SIZE /r2012.jpg
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> 550 File not found
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> TYPE I
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> 200 Type set to I
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> EPSV
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> 229 Entering Extended Passive Mode (|||61165|)
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> STOR r2012.jpg
(000001)2019/3/28 12:50:07 - scims (192.168.163.1)> 150 Opening data channel for file upload to server of "/r2012.jpg"
(000001)2019/3/28 12:54:48 - scims (192.168.163.1)> disconnected.
(000001)2019/3/28 12:54:48 - scims (192.168.163.1)> 226 Successfully transferred "/r2012.jpg"
(000001)2019/3/28 12:54:48 - scims (192.168.163.1)> could not send reply, disconnected.
The text was updated successfully, but these errors were encountered: