View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0016109CMakeCMakepublic2016-05-25 16:082016-06-10 14:31
ReporterIlya 
Assigned ToKitware Robot 
PrioritynormalSeveritytweakReproducibilitysometimes
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0016109: Downloading of a file may hang indefinitely with ExternalProject
DescriptionThe `file(DOWNLOAD` command used by ExternalProject is not limited by any timeouts.

It should, instead, automatically retry (and possibly continue) to download the file.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
(0041094)
Brad King (manager)
2016-05-25 16:35

Specifically, file(DOWNLOAD) calls could be taught to use the INACTIVITY_TIMEOUT. An absolute TIMEOUT is not suitable when the file size and connection speed is not known.
(0041096)
Ilya (reporter)
2016-05-25 19:05

Brad, would it be possible to retry download afterwards?
(0041107)
Brad King (manager)
2016-05-26 09:01

Recent changes merged in this topic:

 Merge topic 'ExternalProject-improve-retry'
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e07f7e6c [^]

improve retry support. Please try it out. See also discussion here:

 [Patch] ExternalProject: fix retry logic if error occurs
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16421 [^]
(0041112)
Ilya (reporter)
2016-05-31 12:56

Brad,

Will it continue download or start it over?
(0041113)
Brad King (manager)
2016-05-31 13:06

Re 0016109:0041112: IIUC the retry will start over. The file(DOWNLOAD) command has no way to request a continued download.
(0041114)
Ilya (reporter)
2016-05-31 13:49

Brad,

How hard would it be to add this functionality to file(DOWNLOAD)? I'm thinking to ask / hire someone to do that.
(0041115)
Brad King (manager)
2016-05-31 13:57

Re 0016109:0041114: file(DOWNLOAD) is just a CMake language binding to the curl library. If that library has a way to do this then it will just be a matter of exposing it through an option.
(0041116)
Ilya (reporter)
2016-05-31 14:05
edited on: 2016-05-31 14:07

Brad,

I'm not sure about the library, but the utility has `-C` or `--continue-at`.

In my case this is the preferred solution, because for some reason CMake stops downloading at about 25%. Starting it all over again to stop at 23% or at 28% doesn't solve the issue.

(0041117)
Ilya (reporter)
2016-05-31 14:17

Brad,

I know that 3.6 is scheduled for tomorrow. Would it be possible to include this change in 3.6.1 ?
(0041118)
Brad King (manager)
2016-05-31 14:52

Re 0016109:0041117: No. Patch releases are only for regressions and documentation updates. The feature set for 3.6 is already frozen as announced on the dev list.
(0043006)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

- Issue History
Date Modified Username Field Change
2016-05-25 16:08 Ilya New Issue
2016-05-25 16:35 Brad King Note Added: 0041094
2016-05-25 19:05 Ilya Note Added: 0041096
2016-05-26 09:01 Brad King Note Added: 0041107
2016-05-31 12:56 Ilya Note Added: 0041112
2016-05-31 13:06 Brad King Note Added: 0041113
2016-05-31 13:49 Ilya Note Added: 0041114
2016-05-31 13:57 Brad King Note Added: 0041115
2016-05-31 14:05 Ilya Note Added: 0041116
2016-05-31 14:07 Ilya Note Edited: 0041116 View Revisions
2016-05-31 14:17 Ilya Note Added: 0041117
2016-05-31 14:52 Brad King Note Added: 0041118
2016-06-10 14:29 Kitware Robot Note Added: 0043006
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker