Uploaded image for project: 'Dev - Nexus Repo'
  1. Dev - Nexus Repo
  2. NEXUS-20453

Browse operations can be very slow when using content selector permissions


    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.15.2, 3.16.1
    • Fix Version/s: 3.18.0
    • Component/s: Security
    • Labels:



      When a repository contains millions of assets, and content selector privileges are being used to filter nearly (or entirely) all of that content from certain users, the requests to retrieve content for the browse tree in the UI can take quite an amount time, often timing out.

      Changes Resulting From This Issue Being Fixed

      This main performance issue / timeouts browsing has been resolved, however, it does come with some changes that users will need to pay attention to.

      If using content selector privileges to hide content from users, pay close attention to the following notes

      • The content selector expression is now evaluated against the list of items directly below( one level only) a certain node in the tree, no longer traversing deeper into the tree to find an asset that the user has access to.  This will most likely require changes to your content selectors, detailed quite nicely in this doc referencing nxrm2 https://support.sonatype.com/hc/en-us/articles/213464568-Browse-storage-doesn-t-work-for-users-with-restricted-read-access-
      • Filtering of the browse tree is no longer supported(and the UI control no longer available), based on the fact that we are no longer traversing down the tree (past immediate child nodes) when doing queries, the filter implementation simply couldn't function any longer as currently designed.  Not to say something similar won't come back in the future
      • With the changes to the schema behind this data, you will find a small increase in database size (as more data is being stored with the records, to make the data access much quicker, an example would be a 6 million+ asset database coming in at ~34g bumping up to 35g)
      • In the same vein as the above bullet, you will find that the 'Repair: Rebuild repository browse Task' also runs a bit longer than usual, for example, on a 6 million+ asset system, before the change it took roughly 1h10m to complete the task, after the changes it now takes about 1h45m to complete.  Though if you have such a large system, this shouldn't be a very large concern, based on the next bullet point (and the fact that this rebuild only needs to run once on upgrade)
      • In deployments where millions of assets are hidden from users, it will be quite refreshing to find near instantaneous results when browsing through the tree content


          Issue Links



              Unassigned Unassigned
              dbradicich Damian Bradicich
              Last Updated By:
              Peter Lynch Peter Lynch
              0 Vote for this issue
              4 Start watching this issue


                Date of First Response: