Configurablle Nuget feed timeout

Legacy Uncategorised
1

Hi Paul,

would it be possible to have the Nuget feed discovery time out on the create release page configurable. Quite regularly finding that this is timing out and requires a number of retries to get the available nuget packages.

In fact have just upped the time out figure in site.js in order to reduce the incidence of this.

Thanks

Bruce

2

Hi Bruce,

In case this is still a problem, I’ve made the same tweaks in the Octopus code, and they’ll be included in the next release.

Paul

3

Hi Paul,

We are still seeing an issue with this, plus starting today the following error when downloading packages for a depoy

2012-07-16 12:43:49 DEBUG Finding package (attempt 1 of 5)2012-07-16 12:45:29 ERROR Unable to download package: The operation has timed out System.Net.WebException: The operation has timed out
Server stack trace:
at System.Net.HttpWebRequest.GetResponse()at NuGet.RequestHelper.GetResponse(Func`1 createRequest, Action`1 prepareRequest, IProxyCache proxyCache, ICredentialCache credentialCache, ICredentialProvider credentialProvider)
at NuGet.HttpClient.GetResponse()
at NuGet.RedirectedHttpClient.GetResponseUri(HttpClient client)
at NuGet.RedirectedHttpClient.EnsureClient()
at System.Lazy`1.CreateValue()Exception rethrown 
at [0]:at System.Net.HttpWebRequest.GetResponse()
at NuGet.RequestHelper.GetResponse(Func`1 createRequest, Action`1 prepareRequest, IProxyCache proxyCache, ICredentialCache credentialCache, ICredentialProvider credentialProvider)
at NuGet.HttpClient.GetResponse()
at NuGet.RedirectedHttpClient.GetResponseUri(HttpClient client)
at NuGet.RedirectedHttpClient.EnsureClient()at System.Lazy`1.CreateValue()
at System.Lazy`1.LazyInitValue()
at NuGet.RedirectedHttpClient.get_CachedClient()
at NuGet.RedirectedHttpClient.get_Uri()
at NuGet.DataServicePackageRepository.get_Culture()
at NuGet.PackageRepositoryExtensions.FindPackagesById(IPackageRepository repository, String packageId)
at NuGet.PackageRepositoryExtensions.FindPackages(IPackageRepository repository, String packageId, IVersionSpec versionSpec, Boolean allowPrereleaseVersions, Boolean allowUnlisted)
at Octopus.Server.Tasks.Deploy.DownloadPackageActivity.FindPackage(Int32 attempt) in c:\BuildAgent\work\7bf5272a44079f5\source\Octopus.Server\Tasks\Deploy\DownloadPackageActivity.cs:line 113
at Octopus.Server.Tasks.Deploy.DownloadPackageActivity.AttemptToFindAndDownloadPackage(Int32 attempt, String cacheDirectory, IPackage& downloadedPackage, String& path) in c:\BuildAgent\work\7bf5272a44079f5\source\Octopus.Server\Tasks\Deploy\DownloadPackageActivity.cs:line 98
at Octopus.Server.Tasks.Deploy.DownloadPackageActivity.AttemptToDownload() in c:\BuildAgent\work\7bf5272a44079f5\source\Octopus.Server\Tasks\Deploy\DownloadPackageActivity.cs:line 62

I upgraded to the 1287 build this morning.

We’re using TC7 as our primary NuGet feed and at a rough estimate there are in the order of 30K packages so I suspect that this may be contributing.

We’ve also got a secondary feed using the NuGet gallery project, we’ve tried 1.6 and 2.0, and both of these with a much smaller set of packages, about 2K, take about 5 minutes to initialise the package collection
when first hit.

Bruce

4

Hi Bruce,

I’ve made some more changes in the latest release to try and extend the timeout on the server side:

Let me know if that improves your experience. The fundamental problem here however is that NuGet is obviously getting slow for lots of feeds. I saw someone else that had built a fast NuGet server, I’ll try to track down the details for you.

Paul

5

Hi Paul,

This one I think http://help.octopusdeploy.com/discussions/suggestions/84-feature-request-refresh-nuget-feeds-only-when-changed

Regards

Bruce

6

Hi Paul,

Thanks for your reminder about the fast NuGet server. It turns out that this acan make quite a difference.

We’ve been using TeamCity7s built in Nuget service but with about 35K packages it had been proving to be a bit painful when setting up a release, especially as we’re looking at 25-30 packages in a release at the moment. We’ve also got a second NuGet service built from the NuGet Server project made available by the NuGet team for QAT and beyond, which only had about 1K packages.

Following our conversation through the support site the other day we’ve implemented the NuGet with Lucene server in place of both the above. This means that rather than hitting the Create Release button and having to wait 2-5 mins sometimes longer for the page to populate the package dropdowns we’re now seeing sub 1 minute load of the page.

Regards Bruce

Bruce Keen
15below ltd : 15below Australia pty ltd

E: bruce.keen@15below.com
• @15below_travel

7

That’s great to know Bruce. A minute still seems like a long time to wait, so I will look into whether there are ways to search for multiple packages at once in NuGet.

Paul

8

Hi Paul,

Believe me it’s made a significant change to the feel of Octopus to have it sub minute. It also makes a difference on deploy.

We’ve been experimenting with Octo.exe to do auto deploys after build and before the Lucene server this was taking about 11 mins to build the release, once they were available then it took 25seconds

Bruce

Bruce Keen
15below ltd : 15below Australia pty ltd

E: bruce.keen@15below.com
• @15below_travel

9

Bruce,

Glad to hear you’ve been able to use my NuGet.Server + Lucene project.

I just posted a new build to https://github.com/themotleyfool/NuGet/downloads that has a few performance enhancements that may improve Octopus behavior. Specifically, this version attempts to track package download counts and refresh the index asynchronously.

Chris