cloudmatrix/esky — Issue #6: Infinite loop upon update
Author: vkosh
Created: 2012-01-30 12:39:42+00:00
State: open

There's a number of possibilities to achieve infinite update behaviour in DefaultVersionFinder.fetch_version_iter:
request for update -> error downloading or error saving update (exception in DefaultVersionFinder._fetch_file_iter) -> retry

For example the cases may be:
1) Request to index returned file that's not available on update server for some reason. E.g. index file generated from DB and doesn't sync (even for a short time) with file system on update server.
2) Remote user machine hasn't enough space to save downloaded update.

In my case one client of thousands tries to update with such a message in webserver log (about 10 requests per second along hours):
xx.xx.xx.xx - - "GET /updates/app-0.1.win32.0.2.patch HTTP/1.1" 200 36300 "-" "Python-urllib/3.2"
The patch size is more than 200Kb, but every time there is 36300 bytes in log. That's really strange. May be there's a sort of race condition with urllib on windows or download timeout (but it's set to default on client).
And the really frustrating is that I can't do anything with this client. Producing 403, 404 or "connection refused" for him on this patch doesn't do the thing, because open_url in _fetch_file_iter leads to exception raising (descendant of EnvironmentError) in urllib and retrying to download the patch.

So I've desided to do two things in custom implementation of version finder:
1) replace urllib with tornado http client (which's used in my app),
2) limit attempts and intervals of downloading update per update session.

But I have no ideas how to fix correctly this esky behaviour on DefaultVersionFinder level.