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

Added handling for cache not being accessible #1764

Merged
merged 1 commit into from Jun 29, 2016

Conversation

Projects
None yet
2 participants
@xavierzwirtz
Contributor

xavierzwirtz commented Jun 27, 2016

Fixes #1758

I moved the directory creation to when the cache is loaded from the dependencies file. It tries to create the directory if it doesn't exist, and doesn't include the cache in the feed list or cache list if it fails.

@xavierzwirtz

This comment has been minimized.

Show comment
Hide comment
@xavierzwirtz

xavierzwirtz Jun 27, 2016

Contributor

This broke the Paket.DependenciesFile.ParserSpecs.should read config with caches test. It is no longer returning any caches that are not accessible.

Contributor

xavierzwirtz commented Jun 27, 2016

This broke the Paket.DependenciesFile.ParserSpecs.should read config with caches test. It is no longer returning any caches that are not accessible.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jun 28, 2016

Member

yeah we should not do this during parsing.

Member

forki commented Jun 28, 2016

yeah we should not do this during parsing.

@xavierzwirtz

This comment has been minimized.

Show comment
Hide comment
@xavierzwirtz

xavierzwirtz Jun 28, 2016

Contributor

Where would be the best place to do it? It feels like it needs to be done for every case where the cache would be accessed, the earlier in the process the better. Otherwise, in cases where there are a lot of dependencies there will be a slow call out to the network for every restore. What about an optional argument to DependenciesFile.ReadFromFile, defaulting to true, that ignores caches that are not accessible?

Contributor

xavierzwirtz commented Jun 28, 2016

Where would be the best place to do it? It feels like it needs to be done for every case where the cache would be accessed, the earlier in the process the better. Otherwise, in cases where there are a lot of dependencies there will be a slow call out to the network for every restore. What about an optional argument to DependenciesFile.ReadFromFile, defaulting to true, that ignores caches that are not accessible?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jun 28, 2016

Member

I think it should be done differently. We "just" need to make the cache calls more robust. we should not filter them out.

Member

forki commented Jun 28, 2016

I think it should be done differently. We "just" need to make the cache calls more robust. we should not filter them out.

@xavierzwirtz

This comment has been minimized.

Show comment
Hide comment
@xavierzwirtz

xavierzwirtz Jun 28, 2016

Contributor

Pushed error handling. This resolves the issue, but there is now a pretty hefty speed penalty when the cache is not accessible. I think it would be better if there was a single check for cache accessibility, because as it stands now there are 2 * packageCount, and each check can take upwards of 2 seconds to timeout.

Contributor

xavierzwirtz commented Jun 28, 2016

Pushed error handling. This resolves the issue, but there is now a pretty hefty speed penalty when the cache is not accessible. I think it would be better if there was a single check for cache accessibility, because as it stands now there are 2 * packageCount, and each check can take upwards of 2 seconds to timeout.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jun 29, 2016

Member

Maybe additionally we can now blacklist caches during the lifetime of one
paket call. But I think it was important to first make the calls safe
On Jun 28, 2016 6:49 PM, "Xavier Zwirtz" notifications@github.com wrote:

Pushed error handling. This resolves the issue, but there is now a pretty
hefty speed penalty when the cache is not accessible. I think it would be
better if there was a single check for cache accessibility, because as it
stands now there are 2 * packageCount, and each check can take upwards of
2 seconds to timeout.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1764 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADgNOogpjIQ6sgp6B4LvX04Y-fVzaVBks5qQVC1gaJpZM4I_RFi
.

Member

forki commented Jun 29, 2016

Maybe additionally we can now blacklist caches during the lifetime of one
paket call. But I think it was important to first make the calls safe
On Jun 28, 2016 6:49 PM, "Xavier Zwirtz" notifications@github.com wrote:

Pushed error handling. This resolves the issue, but there is now a pretty
hefty speed penalty when the cache is not accessible. I think it would be
better if there was a single check for cache accessibility, because as it
stands now there are 2 * packageCount, and each check can take upwards of
2 seconds to timeout.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1764 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADgNOogpjIQ6sgp6B4LvX04Y-fVzaVBks5qQVC1gaJpZM4I_RFi
.

@forki forki merged commit 9da53ef into fsprojects:master Jun 29, 2016

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@xavierzwirtz

This comment has been minimized.

Show comment
Hide comment
@xavierzwirtz

xavierzwirtz Jun 29, 2016

Contributor

Thanks! This is already a lot better. I am able to run paket restore now without being vpn'd into the main office.

Contributor

xavierzwirtz commented Jun 29, 2016

Thanks! This is already a lot better. I am able to run paket restore now without being vpn'd into the main office.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment