Conversation
| { | ||
| // File could not be deleted because it is locked. | ||
| // Calling Garbage collector explicitly to remove the object from the heap. | ||
| GC.Collect(); |
There was a problem hiding this comment.
Will this actually solve the problem? Or is there a more fundamental issue with how the SDK is supporting parallel operations?
There was a problem hiding this comment.
I looked deeper into the code. Looks like the root cause is different. I will look further and update my findings here.
There was a problem hiding this comment.
Couldn't figure out the root cause. Here are few observations.
-
No issue with the completion of upload and starting of deletion logic. Verified this by putting a suitable wait after upload completes. This did not fix the problem.
-
I bypassed the parallel operations logic and performed upload right in the SyncSFItem.cs file. This too did not fix the problem.
From these observations I felt that the issue is with uploaders object that we get from ShareFile.api.client library but when I looked into their code, there doesn't seem to be any problem. They are performing cleanups whenever possible.
rgmills
left a comment
rgmills
left a comment
There was a problem hiding this comment.
Hold for updates from @vkvikaskmr
3 participants
UploadAction class, while uploading the file creates a reference and points to FileInfo object. This object stays in the heap even after the CopyFileItem method of class UploadAction goes out of scope. We cannot call dispose() method on FileInfo object as it does not implement IDispose interface. Hence we are calling Garbage Collector explicitly.