Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-14232

Performance issue when creating resource_set in UMA with many existing resource_set


    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s:
    • Fix Version/s: 6.5.1, 6.0.1, 7.0.0, 5.5.2
    • Component/s: UMA
    • Labels:
    • Sprint:
      AM Sustaining Sprint 59
    • Story Points:
    • Needs backport:
    • Support Ticket IDs:
    • Needs QA verification:
    • Functional tests:
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description


      Bug description

      When an UMA provider holds many resource_sets, creating a new resource_set takes a long time.

      From my testing: 3700 resource_set; adding a new one takes between 5 and 7seconds
      That time would increase with the number of existing resources.
      Customer testing used 300K resource_sets and showed delays of up to 13 seconds.

      How to reproduce the issue

      1. Create an OAuth2 client with scope uma_protection
      2. Configure UMA server (from Dashboard > Configure > OAuth Provider > Configure User Managed Access)
      3. Obtain a PAT access token (OAuth2 access token with scope uma_protection):
        curl --request POST --header 'authorization: Basic cnNjbGllbnQ6cnNwYXNzd29yZA==' --data 'grant_type=password&username=demo&password=changeit&scope=uma_protection' 'http://openam.example.com:8080/openam/oauth2/access_token'
      1. Register a resource using the PAT obtained in 3.
        curl --request POST --header 'Content-Type: application/json' --header "Authorization: Bearer $PAT" --data '{"name" : "New_Resource","resource_scopes" : ["read"], "labels" : ["New_resource_Label"],"type" : "MyType"}' 'http://openam.example.com:8080/openam/uma/resource_set'
      1. Create thousands of those and observe how the creation time increases
      Expected behaviour
      Short creation time
      Current behaviour
      As number of resource_set increases, so does the creation time

      Code analysis

      When a resource_set is created, an internal process also creates a registeredResourceType. The registeredResourceType is part of the AM sunEntitlementService which is loaded with the rest of the AM configuration at start up (that takes some time with thousands of registeredResourceType ...).
      When a new registeredResourceType is created, a notification is received by AM. It looks like:

      ServiceConfigManagerImpl(iPlanetAMPolicyService):objectChanged Received notification for DN: ou=086336b2-c940-40db-959a-efef7eb423360,ou=registeredResourceTypes,ou=default,ou=OrganizationConfig,ou=1.0,ou=sunEntitlementService,ou=services,dc=openam,dc=forgerock,dc=org

      Following that entry in the logs, it looks like AM goes through each existing registeredResourceType to check the cache. The entries in the logs look like:

      ServiceConfigImpl::getInstance: called: ou=d2a66d34-226d-4b0e-8015-9f94057f601566,ou=registeredResourceTypes,ou=default,ou=OrganizationConfig,ou=1.0,ou=sunEntitlementService,ou=services,dc=openam,dc=forgerock,dc=org

      In my test with 3700 resource_sets, the notification timestamp was 01/11/2019 11:19:20:015 AM GMT; it then immediately proceeded to call each entry and only finished at timestamp 01/11/2019 11:19:25:553 AM GMT, more than 5 seconds later.


          Issue Links



              • Assignee:
                sachiko Sachiko Wallace
                nathalie.hoet Nathalie Hoet
              • Votes:
                2 Vote for this issue
                7 Start watching this issue


                • Created: