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


    • 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:


      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)


      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.


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


      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.


          Issue Links



              mbucher Michael Bucher
              plynch Peter Lynch
              Maxim Cheusov
              Last Updated By:
              Peter Lynch Peter Lynch
              Nexus - Platform
              0 Vote for this issue
              7 Start watching this issue


                Date of First Response: