-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible fix for SFSDK-60 #37
base: master
Are you sure you want to change the base?
Conversation
ShareFileSnapIn/SyncSfItem.cs
Outdated
{ | ||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hold for updates from @vkvikaskmr
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.