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

CTS update fails due to attribute conflict

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 11.0.0, 11.0.1
    • Fix Version/s: 11.0.2, 12.0.0
    • Component/s: CTS
    • Labels:
    • Support Ticket IDs:

      Description

      The CTS update (CoreTokenAdapter#createOrUpdate) logic depends on the Token not changing between the time it is read and the time the LDAP modify operation is performed.

      If this is not the case, due to replication changes for example then there will be at least one (ConstraintViolationException) and perhaps more exceptions that could be thrown.

      Example:

      org.forgerock.openam.cts.exceptions.SetFailedException:
      CTS: Failed to set Token:
      org.forgerock.openam.cts.api.tokens.Token
          coreTokenObject = 5648 bytes
          coreTokenId = -8430736164319648498
          coreTokenExpirationDate = 12/12/13 5:57 AM
          coreTokenType = SESSION
          coreTokenUserId = id=0570378a-686c-4a93-93c8-bc811a17d0b8,ou=user,o=customer,ou=services,dc=openam,dc=forgerock,dc=org
          coreTokenString01 = 1386844956
          coreTokenString02 = AQIC5wM2LY4SfcyQqE-jTHO-gQhQkaO3crcQmYOSeg-dwQU.*AAJTSQACMDYAAlNLABQtODQzMDczNjE2NDMxOTY0ODQ5OAACUzEAAjAy*
          at org.forgerock.openam.cts.impl.CoreTokenAdapter.updateOrCreate(CoreTokenAdapter.java:239)
          at org.forgerock.openam.cts.CTSPersistentStore.update(CTSPersistentStore.java:163)
          at com.iplanet.dpro.session.service.SessionService.saveForFailover(SessionService.java:3253)
      ...
      Caused by: org.forgerock.opendj.ldap.ConstraintViolationException: Attribute or Value Exists: Entry coreTokenId=-8430736164319648498,ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=forgerock,dc=org cannot be modified because it would have resulted in one or more duplicate values for attribute coreTokenExpirationDate:  20131212055736-0500
          at org.forgerock.opendj.ldap.ErrorResultException.newErrorResult(ErrorResultException.java:173)
          at com.forgerock.opendj.ldap.AbstractLDAPFutureResultImpl.setResultOrError(AbstractLDAPFutureResultImpl.java:125)
          at com.forgerock.opendj.ldap.LDAPClientFilter$1.modifyResult(LDAPClientFilter.java:326)
          at com.forgerock.opendj.ldap.LDAPClientFilter$1.modifyResult(LDAPClientFilter.java:79)
          at com.forgerock.opendj.ldap.LDAPReader.decodeModifyResult(LDAPReader.java:1055)
      

      This has been noted as a result of customer testing in the ZenDesk support ticket 2177.

      This style of problem would be possible in any SFO environment where operations for a particular user are being shared between OpenAM instances, rather than where a sticky load balancer is directing a user to the same instance each time.

        Attachments

          Activity

            People

            • Assignee:
              peter.major Peter Major
              Reporter:
              sachiko Sachiko Wallace
              QA Assignee:
              Filip Kubáň
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: