Maven feed for cache

[scott.wright_8356]

Hi Support,

We have a public Maven feed for which we cannot see the artefacts. We left it for 20 minutes, but it showed loading artefacts.

Regards Scott

[scott.wright_8356]

We have an issue where Maven downloads from the public repository (https://repo1.maven.org/maven2) are taking forever. It is timing out.

[scott.wright_8356]

We are also getting the following error when trying to access packages on the Feed

An error occurred in the web application: Object reference not set to an instance of an object.

URL: http://proget.wtg.zone/feeds/Maven/nekohtml/Neko HTML/1.9.6.2
Referrer: https://proget.wtg.zone/packages?FeedId=3&Cache=cached&skip=0&take=1000
User: SW
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Edg/122.0.0.0
Stack trace: at Inedo.ProGet.Feeds.Maven.MavenFeed.Inedo.ProGet.Feeds.IBrowsablePackageFeed.ListPackageVersionsAsync(BrowsablePackageId id)
at Inedo.ProGet.WebApplication.Pages.Packages.PackagePageBase.CreateChildControlsAsync()
at Inedo.ProGet.WebApplication.Pages.ProGetSimplePage.InitializeAsync()
at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync()
at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

[scott.wright_8356]

This is happening across all Maven feeds even private ones

An error occurred in the web application: Object reference not set to an instance of an object.

URL: http://proget.wtg.zone/feeds/Maven-WTG/com.cargowise.eservices/Maven Health Check API/1.0.0
Referrer: https://proget.wtg.zone/packages?FeedId=20&Cache=all
User: SW
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Edg/122.0.0.0
Stack trace: at Inedo.ProGet.Feeds.Maven.MavenFeed.Inedo.ProGet.Feeds.IBrowsablePackageFeed.ListPackageVersionsAsync(BrowsablePackageId id)
at Inedo.ProGet.WebApplication.Pages.Packages.PackagePageBase.CreateChildControlsAsync()
at Inedo.ProGet.WebApplication.Pages.ProGetSimplePage.InitializeAsync()
at Inedo.Web.PageFree.SimplePageBase.ExecutePageLifeCycleAsync()
at Inedo.Web.PageFree.SimplePageBase.ProcessRequestAsync(AhHttpContext context)
at Inedo.Web.AhWebMiddleware.InvokeAsync(HttpContext context)

[scott.wright_8356]

We are running ProGet 2023.31 and the problem with the Maven feeds is occurring on our test system as well.

[atripp]

Hi @scott-wright_8356 ,

Can you try downgrading to 2023.30? I see some Maven changes, and any time there's a possibility of a regression. That will at least tell us where the issue might be.

Thanks,
Alana

[scott.wright_8356]

@atripp We downgraded, but still no luck. It is incredibly slow and still getting the Object Reference errors. The 500 error in accessing Maven packages also occurs in both versions. What we did find, looking at our build logs, was the download from the feed was incredibly slow. All features were turned off the feed, and still, the download was slow. We went through the connectors and removed them one by one. We found that our connector for Google Andriod was incredibly slow, it was reporting healthy but was killing the feed.

Is there a way to tell the speed of a public connector response so we can see the really slow ones and see if they are outdated? I think this might be a deprecated feed URL maybe.

[atripp]

Hi @scott-wright_8356 ,

Thanks; it sounds like the underlying issue is indeed Google Android connector you added. I don't have an information or idea on why that might be the case... some third-party repos (Maven, PyPi, NuGet, etc.) are just really slow and buggy.

ProGet is basically acting like a proxy server here, so "garbage in, garbage out" applies - if the connector is slow and error-prone, then you will experience slowness and errors.

Sometimes third-party repos will create packages that don't follow the specifications but just happen to work in certain versions of clients. That could be what's happening here. In cases like that, we can really only address those on a case-by-case basis, and we'd need to know exactly how to reproduce the error and investigate it later.

Best,
Alana