DownloadPackge.Storage initialized twice when library begins from local DownloadPackage json file

[liuhj1018]

I download a large file. I put the downloadpackage json file to the disk. When I reboot the progress and resume from the json file, a error shows the datafile is in use. I find line 25 and line 87 same in the ConcurrentStream.cs and I modify the DownloadPackage.cs. The datafile can be downloaded correctly.

Is it a bug? or I use in a wrong way?
Look forward for reply!

[liuhj1018]

if (File.Exists(processFile))
{
string content = File.ReadAllText(processFile);
var newPack = JsonConvert.DeserializeObject(content);
await downloader.DownloadFileTaskAsync(newPack);
}
else
{
await downloader.DownloadFileTaskAsync(url, tempFile);
}

[bezzad]

DownloadPackage

@liuhj1018 When you check the null condition for storage, don't update storage when it was used before. So, when I want to use the Downloader object again to download another URL, I get it wrong because I use an older storage stream and override the old data with new data.

[bezzad]

Do you stop the Downloader process with the Stop() method and then exit from your app or reboot it?
I ask this question because this issue didn't happen before this and when you call the stop, all processes have been done actually and disposed of this cycle. So, you can continue any time you want.

[liuhj1018]

Do you stop the Downloader process with the method and then exit from your app or reboot it? I ask this question because this issue didn't happen before this and when you call the stop, all processes have been done actually and disposed of this cycle. So, you can continue any time you want.Stop()

No, I don't call the stop method. I just simulate the program or the computer has benn suddenly shut down. This is not normal but happen.
I will check null condition for storage, and the current and the next downloader.

[liuhj1018]

I want to write the Package to the local file using "var packageJson = JsonConvert.SerializeObject(package);". But Where I put the sentence? OnDownloadProgressChanged or OnChunkDownloadProgressChanged method?

[bezzad]

In the case of sudden shutdowns (like a power failure or unexpected program termination), you’ll want to back up the package object, which contains the metadata necessary to resume the download. My Downloader library is designed to resume downloads by serializing the package object as JSON and storing it in a file, database, or another persistent storage. This package can then be passed back to the Downloader to continue the download from where it left off.

When to Serialize and Backup the Package

You’re right to consider the performance impact of serializing the package on every OnProgress event. While backing up on every event would ensure no data is lost, it could indeed be too resource-intensive. To address this, I recommend using a debounce algorithm to limit how often the serialization occurs. This will prevent redundant operations and reduce the performance overhead while ensuring that only the latest package is backed up.

Steps to Take:

1. Use OnDownloadProgressChanged:

   • This is the appropriate place to serialize and back up the package. However, instead of doing it on every single progress event, debounce the operation. For example, you could serialize the package every few seconds or after a certain amount of data has been downloaded.

2. Handling Race Conditions:

   • Since your download process is multithreaded, there's a chance of race conditions where multiple threads might try to access or modify the package concurrently. Make sure to implement proper synchronization (e.g., using locks) to avoid corrupting the package during serialization.

3. Handling Sudden Shutdowns:

   • Since the program might shut down unexpectedly, serializing the package periodically is crucial to ensure you don’t lose progress. While I haven’t tested this exact scenario yet, backing up the package periodically using a debouncing mechanism should provide a good balance between performance and reliability.

Here's a rough idea of how debouncing could be implemented:

private DateTime _lastSerializedTime = DateTime.MinValue;
private readonly TimeSpan _debounceInterval = TimeSpan.FromSeconds(5);

void OnDownloadProgressChanged(object sender, DownloadProgressChangedEventArgs e)
{
    if (DateTime.Now - _lastSerializedTime > _debounceInterval)
    {
        var packageJson = JsonConvert.SerializeObject(package);
        File.WriteAllText("packageBackup.json", packageJson);
        _lastSerializedTime = DateTime.Now;
    }
}

This way, you can ensure the package is backed up regularly without overwhelming the system.
* Serialize the package in the OnDownloadProgressChanged method but apply debouncing to avoid performance issues.
* Be mindful of race conditions in a multi-threaded environment by using synchronization.
* Regular backups of the package object will help recover from sudden shutdowns or crashes without too much data loss.

I haven’t fully tested this particular scenario, but I believe this approach should work for your needs. Let me know if you need any more help with this!

[liuhj1018]

two problems:

1. packageBackup.json write conflict. File.WriteAllTextAsync("packageBackup.json", packageJson);
2. Restart program, downloading file write conflict. Need add Storage null judgment in the DownloadPackage.cs.
   

[bezzad]

I don't Undrestand the right issue. According to the previews answer you must handle race conditions by debouncing and locking objects to prevent write conflict issues. please explain more about what happened.

[liuhj1018]

1.packageBackup.json write conflict. I had used locking object method first, but its efficiency was low. So now I use File.WriteAllTextAsync method.
2.When I generate the local backup.json file, shutdown the program and restart, the file stream is initialized in the ConcurrentStream.cs (line 31) firstly, and then initialized in the DownloadPackage.cs (line 138) secondly. They are conflict. I add Storage nullvalue judgement to avoid initializing twice on the same file.

[ktxiaok]

Hi @bezzad , I think the cause of this problem is that the DownloadPackage.Storage is serialized into JSON. When the JSON file is deserialized, a storage instance will be created which conflicts with the instance created by DownloadPackage.BuildStorage later. I think the property DownloadPackage.Storage isn't supposed to be serialized. It should have an attribute [NonSerialized].

[bezzad]

Sorry for the delayed response; I've been quite busy these past few weeks.
Thanks for your patience—I'm working on it, and I’ll keep you updated with any progress or solutions.

[bezzad]

Hi @liuhj1018 @ktxiaok

Thank you for bringing this issue to our attention! We've made several updates and improvements to the Downloader package. Please test the newly released v3.3.0 and let us know if you're still encountering the issue.
Your feedback is incredibly valuable to us, and we appreciate your patience and support.