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

CTS Entry Already Exists errors without CTS affinity or active passive DS servers


    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Not a defect
    • Affects Version/s: 13.5.0, 5.5.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Needs backport:
    • Support Ticket IDs:
    • Needs QA verification:
    • Functional tests:
    • Are the reproduction steps defined?:
      No (add reasons in the comment)


      Bug description

      When not using CTS affinity or DS active passive configuration, there is a race condition that occurs  during retrieval of an OAuth token, such that an error 500 results.

      How to reproduce the issue

      1. Install a single AM server, with 2 external dir servers proving the config and CTS stores.
      2. Perform a large number of curl requests for an OAuth token e.g. curl --request POST --data "client_id=testoauth&grant_type=password&username=testuser&password=password&client_secret=clientpassword" https://openam.amtest2.com/access/oauth2/access_token
      Expected behaviour
      All of the requests will complete successfully
      Current behaviour
      A number of the requests fail with an error 500.  For these, there are logged entries in CoreSystem and Session debug logs that indicate (taken from AM 5.5.1 environment):
      Diagnostic Message: The entry coreTokenId=<coreTokenId>,ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=test,dc=com cannot be added because an entry with that name already exists
      Matched DN: 
       at org.forgerock.openam.cts.impl.LdapAdapter.create(LdapAdapter.java:111)
       at org.forgerock.openam.sm.datalayer.impl.tasks.UpdateTask.performTask(UpdateTask.java:57)

      Work around

      The documented solution here is https://backstage.forgerock.com/docs/am/6.5/install-guide/#cts-deployment-architectures. , use CTS Affinity, or active/passive CTS dir servers

      Code analysis

      Believe what is happening is that the authentication results in an ldap add request for the coreTokenId to e.g. DS1.  This is then replicated to DS2.  However the subsequent processing then results in an update to the CTS, and the ldap search performed as part of this is performed against DS2, after the add in DS1 but before the replication to DS2.  As a result the update determines that it needs to add the coreTokenId, and the add is then performed against DS1, which fails.


          Issue Links



              • Assignee:
                lawrence.yarham Lawrence Yarham
                lawrence.yarham Lawrence Yarham
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: