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

HA security UI save fails with no error then next save reports "updated in the meantime" errors

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.6.0, 3.9.0
    • Fix Version/s: 3.11.0
    • Component/s: HA
    • Labels:

      Description

      Strange behavior of UI on Nexus HA cluster. When I'm trying to save changes after editing/adding *any security related element in the Administration UI*, Nexus shows waiting screen for 20-30 sec and then Save button continue to be active, when I'm trying to press it again I'm getting an error like: Privilege 'diamond-scrip-run' updated in the meantime.

      Example log message that might be seen in the nexus.log:

      2018-03-08 18:02:35,596-0500 ERROR [qtp819030920-15904] NODE3 admin org.sonatype.nexus.extdirect.internal.ExtDirectServlet - Failed to invoke action method: coreui_Privilege.update, java-method: org.sonatype.nexus.coreui.PrivilegeComponent.update
      java.util.ConcurrentModificationException: Privilege 'diamond-scrip-run' updated in the meantime
          at org.sonatype.nexus.internal.security.model.OrientSecurityConfigurationSource$OrientSecurityConfiguration.concurrentlyModified(OrientSecurityConfigurationSource.java:178)
          at org.sonatype.nexus.internal.security.model.OrientSecurityConfigurationSource$OrientSecurityConfiguration.lambda$8(OrientSecurityConfigurationSource.java:309)
          at org.sonatype.nexus.orient.transaction.OrientOperations.lambda$2(OrientOperations.java:63)
          at org.sonatype.nexus.transaction.OperationPoint.lambda$0(OperationPoint.java:53)
          at org.sonatype.nexus.transaction.OperationPoint.proceed(OperationPoint.java:64)
          at org.sonatype.nexus.transaction.TransactionalWrapper.proceedWithTransaction(TransactionalWrapper.java:56)
          at org.sonatype.nexus.transaction.Operations.transactional(Operations.java:200)
          at org.sonatype.nexus.transaction.Operations.run(Operations.java:155)
          at org.sonatype.nexus.orient.transaction.OrientOperations.run(OrientOperations.java:63)
          at org.sonatype.nexus.internal.security.model.OrientSecurityConfigurationSource$OrientSecurityConfiguration.updatePrivilege(OrientSecurityConfigurationSource.java:303)
          at org.sonatype.nexus.security.internal.SecurityConfigurationManagerImpl.updatePrivilege(SecurityConfigurationManagerImpl.java:214)
          at org.sonatype.nexus.security.internal.AuthorizationManagerImpl.updatePrivilege(AuthorizationManagerImpl.java:260)
          at org.sonatype.nexus.security.authz.AuthorizationManager$updatePrivilege$1.call(Unknown Source)
          at org.sonatype.nexus.coreui.PrivilegeComponent.update(PrivilegeComponent.groovy:175)
          at com.palominolabs.metrics.guice.ExceptionMeteredInterceptor.invoke(ExceptionMeteredInterceptor.java:49)
          at com.palominolabs.metrics.guice.TimedInterceptor.invoke(TimedInterceptor.java:47)
          at org.sonatype.nexus.validation.internal.ValidationInterceptor.invoke(ValidationInterceptor.java:53)
          at 
      
      

      Explanation

      Security (and LDAP) stores have a different behaviour to other stores in NXRM in the face of stale data due to some historical reasons.

      Most configuration stores will attempt to write the data passed back from the UI without any attempt at merging/reconciliation if they encounter stale data (such as when the DB version is greater than the last version loaded into the UI). In other words a "last one wins" approach. This approach was chosen because it's simple and the values in the UI when the user clicks "save" will be what's written to the database.

      The repository stores will also retry when they encounter stale data, but they are a bit smarter and reload the data so the operation can be repeated on top of the latest DB data. This is because almost always we want to merge the new information with existing data.

      However the security stores take a different approach and simply refuse to write what's given in the UI if the version there is behind the latest DB version. It's the same for the LDAP store.

      Expected

      The security stores should act like other admin related stores and work without error regardless of node.

      Workaround

      Turn on sticky sessions and only use one node for admin operations. Or go direct to a specific node for admin operations, rather than through the load-balancer - if the operation fails on one node, move along to the next node - eventually you should reach the node where the last operation originated for the privilege being edited, and Nexus should accept the new edit.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              mbucher Michael Bucher
              Reporter:
              plynch Peter Lynch
              CC:
              Maxim Cheusov
              Last Updated By:
              Peter Lynch Peter Lynch
              Team:
              Nexus - Platform
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Date of First Response:

                  tigCommentSecurity.panel-title