I am using nexus OSS 3.15.2-01 and its new instance.
Issue we are facing is with nuget proxy repos, if i try it manually curl nuget org on nexus server it reaches the URL.
I have created a seperate blob for nuget and new repo nuget_gallery, and provided the nuget org in proxy.
Now exepected is to fetch packages we want from nuget org, so what nexus is doing is it fetches the artifacts along with available versions but when i try to download it it says file not found.
From VS it says,
Severity Code Description Project File Line Suppression State
Error The feed ânexus prod [repo URL]â lists package âMicrosoft.AspNet.WebApi.Client.5.2.7â but multiple attempts to download the nupkg have failed. The feed is either invalid or required packages were removed while the current operation was in progress. Verify the package exists on the feed and try again.
Unable to find package âMicrosoft.AspNet.WebApi.Client.5.2.7â.
How ever the version is fetched in nexus if we browse the repo but even when we try to download it says file not found (0 bytes)
There are no errors or exceptions we found in log.
There is only one warning which is âelastic search exceed and low disk watermarkâ, however there is still 45GBâs of free space available.
Do you have any idea what is the possible cause issue?
Proxy url https:// www.nuget.org/api/v2/ also reachable from the nexus server.
Because in log we are only getting
INFO [elasticsearch[C2E9DA26-EA391506-CF1FDBE4-][management][T#2]] *SYSTEM org.elasticsearch.cluster.routing.allocation.decider - [C2E9DA26-EA391506-CF1FDBE4-] low disk watermark [85%] exceeded on [gC80Xyjg][C2E9DA26-EA391506-CF1FDBE4-][/opt/TestNexus/sonatype-work/nexus3/elasticsearch/nexus/nodes/0] free: 45.5gb[12.5%], replicas will not be assigned to this node
Iâve got the same issue with lots of NuGet Packages from proxied Repositories on Nexus 3.17.0. e.g. Swashbuckle.AspNetCore. It would be great if a fix could be done as fast as possible.
Anything in the request.log for the failed packages?
The screen shows locally cached âfalseâ indicating the file is not in NXRM.
I suspect you pulled the metadata but never pulled the file thus itâs showing up.
-Joe
Hi Joe
First try downloading from Nexus UI: [05/Jul/2019:14:48:12 +0200] âGET /repository/nuget-gallery/Swashbuckle.AspNetCore/4.0.1 HTTP/1.0â 404
Second try downloading with curl: [05/Jul/2019:14:51:08 +0200] âGET /repository/nuget-gallery/Swashbuckle.AspNetCore/4.0.1 HTTP/1.0â 404
With 3.15.2 it can download the artifactsâŚ
Also, if it works for you in 3.15.2, I suspect itâs a different issue than originally reported, as the original poster said they were having the issue in 3.15.2.
We have the same issue today.
Request and error logs are clear but when CI tries to find the package we can see next error:
Failed to download package 'AutoMapper.Extensions.Microsoft.DependencyInjection.7.0.0' from 'https://our.nexus.registry/repository/nuget-group/AutoMapper.Extensions.Microsoft.DependencyInjection/7.0.0'.
Nuget Group contains 2 proxy repos and one of them is nuget.org
Nexus version is 3.18.1-01
Until that moment everything was fine.
Any suggestion why this happening from time to time and how to fix\workaround it?
What else information we can provide to you to help in diagnostics?
I mean that for some reason Nexus returns 404 despite that package was presented in proxy repo. someIp - - [22/Oct/2019:12:34:59 +0000] "GET /repositorynuget-group/AutoMapper.Extensions.Microsoft.DependencyInjection/7.0.0 HTTP/1.1" 404 - 1911 20772 "NuGet .NET Core MSBuild Task/5.3.0 (Linux 3.10.0-1062.1.1.el7.x86_64 #1 SMP Fri Sep 13 22:55:44 UTC 2019)" [qtp661998269-138012] someIp - - [22/Oct/2019:12:34:59 +0000] "GET /repository/nuget-group/AutoMapper.Extensions.Microsoft.DependencyInjection/7.0.0 HTTP/1.1" 404 - 1911 5770 "NuGet .NET Core MSBuild Task/5.3.0 (Linux 3.10.0-1062.1.1.el7.x86_64 #1 SMP Fri Sep 13 22:55:44 UTC 2019)" [qtp661998269-138028] someIp - - [22/Oct/2019:12:35:31 +0000] "GET /repository/nuget-group/AutoMapper.Extensions.Microsoft.DependencyInjection/7.0.0 HTTP/1.1" 404 - 1911 2 "NuGet .NET Core MSBuild Task/5.3.0 (Linux 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017)" [qtp661998269-138024] someIp - - [22/Oct/2019:12:42:43 +0000] "GET /repository/nuget-group/AutoMapper.Extensions.Microsoft.DependencyInjection/7.0.0 HTTP/1.1"
When we started the next build for this parcticular project there was no changes in CI or project configuration and everything worked fine.
2019-10-22 12:34:59,348+0000 WARN [qtp661998269-138012] *UNKNOWN com.sonatype.nexus.repository.nuget.internal.proxy.NugetProxyFacet - Exception java.net.SocketTimeoutException: Read timed out checking remote for update, proxy repo nuget.org-proxy failed to fetch AutoMapper.Extensions.Microsoft.DependencyInjection/7.0.0, content not in cache.
Is there some latency between messages appending in log file? Because when I was inspecting this log for the first time (1-2 minutes after build was failed) I havenât seen that messageâŚ
The reported workaround which may not work for everyone is to use seperate sources in your NuGet setup (effectively bypassing group).
You may also fiddle with the timeout settings in the âUI:Settingsâ capability, however, if Iâm right about the bug, itâs not a reliable workaround as the bug could take an undetermined amount of time to resolve.
It is on the teams radar (as noted by team assignment) but the current NuGet focus is NuGet v3, so the bugs have been taking second place as that is pushed through.
Sorry for not better newsâŚothers may have different analysis.
BTW, there shouldnât be any latency to speak of. You can tail the logs real time. It is possible there is more than one issue, but the one you describe to me sounds like that bug.
I ran into a similar problem and discovered it was an issue with the outbound web proxy. Our corporate proxy allowed âwww . nuget . orgâ, but when nuget artifact downloads were attempted, a redirect to âglobalcdn . nuget . orgâ was performed. Since âglobalcdn . nuget . orgâ was not allowed on our corporate proxy, this caused artifacts to show up with 0 bytes since they could be found with the search against âwww . nuget . orgâ, but the download against âglobalcdn . nuget . orgâ was not working.