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

    • Location:
      External

      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:
            1 Start watching this issue

              Dates

              Created:
              Updated:

                Sync Status

                Connection: RTFACT Sync
                RTMID-26517 -
                SYNCHRONIZED
                • Last Sync Date: