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

Security should cache created WildcardPermission objects, not recreating them over and over again

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.6, 2.1
    • Component/s: Security
    • Labels:
      None

      Description

      Problem with security is that it's written in "dry" way. Domain object does not really exists, and (usually Modello generated) configuration object are used directly for actions like lookups and other. Related issue was fixed, but clearly reflected the problem:

      https://github.com/sonatype/security/commit/7176ee1b68c29679091b58054773bd716514fc87

      The configuration objects are suited for persisting, hence, they are not optimized for "runtime". This kind of their use is just wrong.

      What happens is that the model says "permission Z is a string a:b:c", but Security and Shiro "speaks" in WildcardPermission. Hence, whenever a permission is retrieved, what actually happens is new WildcardPermission("a:b:c").

      Obviously, this is not noticeable on small scale, but it does not scale with bigger numbers (count of permissions being fetched from a Realm) very well...

      This affects all Nexus versions.

      Typical case: tested with Nexus 2.1-SNAPSHOT. Created 850 staging repositories under one single profile, and queried for them over REST. Staging REST tries to filter the returned list, by doing security checks. The query was running for 48 minutes (used plain XML realm and user "deployment", as user "admin" is special, and same query for him finished in 2.5seconds!). During these 48 minutes, Yourkit showed that that Nexus spends 97% of CPU time in org.sonatype.security.realms.XmlRolePermissionResolver.resolvePermissionsInRole(String), and JVM allocated 17M object, out of what 16.5M were Shiro's WildcardPermission instances.

        Attachments

          Activity

            People

            • Assignee:
              cstamas Tamás Cservenák
              Reporter:
              cstamas Tamás Cservenák
              Last Updated By:
              Rich Seddon
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Date of First Response: