Uploaded image for project: 'Artifactory Binary Repository'
  1. Artifactory Binary Repository
  2. RTFACT-26507

Add PackageBaseAddress endpoint to NuGet v3 repos

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: 7.21.0, 7.27.10
    • Fix Version/s: None
    • Component/s: NuGet
    • Labels:
      None
    • Environment:

      7.21.13 Pro in Kubernetes deployed with Helm
      Checked against latest 7.27 as well

      Description

      The NuGet v3 API exposed by Artifactory does not provide an endpoint for the 'Package content' resource.

      NuGet clients expect this resource to be available so that when a project asks for a specific version, they can efficiently tell whether a given source has that version available. You can see an example of this working on NuGet.org here: 

      https://api.nuget.org/v3-flatcontainer/xunit/index.json 

      The client then can directly request for the package at the same resource, like this:

      https://api.nuget.org/v3-flatcontainer/xunit/2.4.1/xunit.2.4.1.nupkg 

      NuGet clients will fall back to a v2-ish behaviour if they can find the RegistrationsBaseUrl resource (which Artifactory provides) - however this means the client then paginates through all of the pages provided in that response (NuGet.org example below

      https://api.nuget.org/v3/registration5-gz-semver2/xunit/index.json

      This pagination causes enormous memory consumption for Artifactory, and will crash the application if a moderate number of clients attempt restores against packages with high version counts (>15,000 in our case for one package). This was previously reported as RTFACT-25080 - in our case we are seeing Artifactory 7.21.13 consume 90GB of memory to respond to all of the requests. I'm not asking you to fix that, necessarily, I think that this can be addressed by providing the Package Content resource instead.

      You can also see a customer raising this as an issue against NuGet itself here

      I've attached a client-side log of the behaviour; you'll see by the end the client is waiting 30+seconds for responses as the server is overwhelmed.

        Attachments

          Activity

            People

            Assignee:
            Unassigned
            Reporter:
            cailyoung Cail Young
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: