Feature #935
Multiple related change modifications should map to a single, retriable, upload operation
| Status: | Closed | Start date: | 07/25/2011 | |
|---|---|---|---|---|
| Priority: | Medium | Due date: | ||
| Assignee: | Panagiotis Kanavos | % Done: | 0% |
|
| Category: | Core | Spent time: | - | |
| Target version: | Synching version | Estimated time: | 24.00 hours |
Description
Operations on even medium sized files result in multiple change notifications. It is not possible to detect when an operation finishes. Therefore, it should be possible to create one upload operation that corresponds to a single upload operation. When the operation is ready to execute, the client should check whether the file is already opened. If the file is closed, proceed with the upload.
If the file is open, either:
- Requeue the operation for later execution, perhaps with a small delay
- Or try to upload a previous version (e.g. using the shadow volume API). Even in this case, the operation should be retried at a later time to upload changes that happen after the file closes.
History
#1 Updated by Panagiotis Kanavos over 12 years ago
- Estimated time set to 24.00
#2 Updated by Panagiotis Kanavos over 12 years ago
- Target version set to Synching version
#3 Updated by Panagiotis Kanavos over 12 years ago
- Status changed from New to Closed
Addressed by retrying operations that can't open files for reading.
#4 Updated by Panagiotis Kanavos over 12 years ago
Change operations are also filtered so that no new actions are scheduled for files that are already being processed