Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Restoring multiple packages fails regularly
-
When the package cache is empty and i restore a solution that contains multiple nuget packages the restore fails regularly. I allways receive the error: "Connector error: The operation has timed out."
I have to wait a couple of minutes until it works. I don't have this issue when i restore the packages from visual studio with the v3 nuget.com feed. I happens only when i use proget and the v2 nuget.com feed on a connector.
Level: Error
Category: Connector
Message: Connector error: The operation has timed out.Details: Request URL: https://www.nuget.org/api/v2/Packages(Id='System.Runtime.Serialization.Formatters',Version='4.3.0')?semVerLevel=2.0.0
System.Net.WebException: The operation has timed out.
at System.Net.HttpWebRequest.RunWithTimeoutWorker[T] (System.Threading.Tasks.Task1[TResult] workerTask, System.Int32 timeout, System.Action abort, System.Func1[TResult] aborted, System.Threading.CancellationTokenSource cts) [0x000f8] in <048f685b456c4326be453e3cc3faae14>:0
at System.Net.HttpWebRequest.EndGetResponse (System.IAsyncResult asyncResult) [0x00020] in <048f685b456c4326be453e3cc3faae14>:0
at System.Threading.Tasks.TaskFactory1[TResult].FromAsyncCoreLogic (System.IAsyncResult iar, System.Func2[T,TResult] endFunction, System.Action1[T] endAction, System.Threading.Tasks.Task1[TResult] promise, System.Boolean requiresSynchronization) [0x0000f] in <81342d83acda4c5590ec19c7afdf26b9>:0
--- End of stack trace from previous location where exception was thrown ---at Inedo.ProGet.Feeds.StrongConnector.GetDirectResponseAsync (System.String url) [0x000eb] in <6a03994888e145da81d6016fd555fffb>:0
at Inedo.ProGet.Feeds.StrongConnector.GetCachedResponseAsync (System.String url) [0x000a8] in <6a03994888e145da81d6016fd555fffb>:0
at Inedo.ProGet.Feeds.StrongConnector.GetCachedTextReaderAsync (System.String url) [0x00075] in <6a03994888e145da81d6016fd555fffb>:0
at Inedo.ProGet.Feeds.NuGet.NuGetFeedClient.PerformRequestWithAbsoluteUrlAsync (System.String fullUrl) [0x000d9] in <6a03994888e145da81d6016fd555fffb>:0
-
Long story short, your workstation is overwhelming your server with network connections.
Remember that the NuGet.org not only runs on a massive web farm with dozens of load-balanced servers, but it's a static-file based index that's done mostly with CDN-based files.
Each request you make to ProGet, on the other hand, needs to be authenticated, checked for vulnerabilities, licenses, sent to connectors, etc. And I would be surprised if your server is more powerful than your workstation.
There are some features in ProGet Basic like metadata caching that will help, but ultimately when you scale to more developers you ought to invest in better server hardware and eventually load balancing. See https://blog.inedo.com/proget-free-to-proget-enterprise
-
Well, i'm talking about restoring 40-60 packages and i'm running proget locally on a docker container.
-
Oh; yeah that'll definitely do it.
50 packages yields hundreds of requests to a NuGet feed (ProGet). Each request to ProGet is then forwarded to Nuget.org. Add to that Docker request routing, PostGres network connections... and all of this on a single machine, calling itself over network channels...
You're basically DoS-ing yourself ;)
-
I still wonder why this works from visual studio with a direct nuget.org connection.
Could you please check out that you are re-using the socket connection instead of creating new ones?https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/
This could explain the strange wait states and the exception that's got thrown.
-
This is why it works directly...
Remember that the NuGet.org not only runs on a massive web farm with dozens of load-balanced servers, but it's a static-file based index that's done mostly with CDN-based files.
Each request you make to ProGet, on the other hand, needs to be authenticated, checked for vulnerabilities, licenses, sent to connectors, etc.
The sockets are not getting exhausted, the async awaits are timing out. This is exactly what to expect in a connection overload situation, which will be common place in the way you're using ProGet.
ProGet is not designed nor supported as a desktop tool.
-
Well, you are wrong, other nuget projects like BaGet are able to solve this.
They don't offer such a range of features, but i prefer a more stable solution
than proget is at the moment. Also BaGet supports the v3 protocol,
which is missing in proget since years.
-
Actually, I'm not wrong; ProGet is simply not designed for your use case. It is infinitely more stable in the use cases it was designed for. ProGet also can't bake you muffins; an "oven" is much more suited for this purpose.
There are lots of tools that solve different problems, and ProGet is not designed as a desktop-based, single-user "server" for personal use. We have no intention of building such a tool; our tools are designed for teams to work together, not power tools for single users.
Anyways, it looks like found the tool that you're looking for. Best of luck.
