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

Repo 2 to Repo 3 (Postgres) Upgrade Migration Hangs when 'IQ Audit & Quarantine Capability' is Enabled in Repo 2

    Details

    • Notability:
      2

      Description

      Migrating from Repo 2 to Repo 3 (running Postgres) can hang when the IQ: Audit & Quarantine capability is enabled on the Repo 2 side.

      To reproduce:

      1. On the Repo 2 side, configure an IQ connection and enable the "IQ: Audit & Quarantine" capability on a repo e.g. Central.
      2. Setup a Repo 3 instance running Postgres.
      3. Proceed to migrate the Repo 2 instance to Repo 3 (In the Upgrade UI, select default options and migrate all selectable repos).

      Expected:

      Repo 2 instance migrates to Repo 3.

      Actual:

      At the "Preparing" phase, the migration appears to hang i.e. Does not complete to 100% (see hung_migration.png attached) and a thread dump show the following thread in WAITING state:

      "plan-executor-15-thread-1" #654 prio=5 os_prio=31 tid=0x00007f992e845800 nid=0x8507 waiting on condition [0x000070000390f000]"plan-executor-15-thread-1" #654 prio=5 os_prio=31 tid=0x00007f992e845800 nid=0x8507 waiting on condition [0x000070000390f000]   java.lang.Thread.State: WAITING (parking)
       at sun.misc.Unsafe.park(Native Method) - parking to wait for  <0x0000000792ca58b8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
       at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
       at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
       at com.google.common.util.concurrent.Monitor.await(Monitor.java:1184)
       at com.google.common.util.concurrent.Monitor.waitFor(Monitor.java:827)
       at com.google.common.util.concurrent.Monitor$waitFor$0.call(Unknown Source)
       at com.sonatype.nexus.migration.plan.StepExecutor.run(StepExecutor.groovy:111)
       at com.sonatype.nexus.migration.plan.StepExecutor$run.call(Unknown Source)
       at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
       at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
       at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)
       at com.sonatype.nexus.migration.plan.Plan.runSteps(Plan.groovy:253)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:497)
       at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
       at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
       at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:352)
       at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
       at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:68)
       at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)
       at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:157)
       at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:169)
       at com.sonatype.nexus.migration.plan.Plan$_doBegin_closure6.doCall(Plan.groovy:238)
       at com.sonatype.nexus.migration.plan.Plan$_doBegin_closure6.doCall(Plan.groovy)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       at java.lang.reflect.Method.invoke(Method.java:497)
       at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
       at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
       at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264)
       at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
       at groovy.lang.Closure.call(Closure.java:420)
       at groovy.lang.Closure.call(Closure.java:414)
       at groovy.lang.Closure.run(Closure.java:501)
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
       at java.util.concurrent.FutureTask.run(FutureTask.java:266)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
       at java.lang.Thread.run(Thread.java:745)
      

       

      Workaround

      Do not use this workaround if you have quarantine enabled on repo 2 proxy repositories and you are not OK with losing the data related to quarantined items.

      This workaround should only be followed if for a repo in repo 2 you DO NOT have Quarantine enabled on the repo specific IQ :Audit and Quarantine capability

      In order to migrate repositories and their content that have IQ: Audit and Quarantine enabled in repo 2, then one must do either one of these per repository in repo 2:
      1. Delete the IQ: Audit and Quarantine Capability for the given repo.
      2. OR select the IQ: Audit and Quarantine Capability, uncheck the Enabled checkbox on the settings tab and Click Save

      Then also as a final step:
      Select the IQ: Server Connection capability and then uncheck the Enabled checkbox and click Save.

      If you just disable IQ: Server Connection capability and leave the IQ: Audit and Quarantine enabled for a repo, you will not be able to migrate that repo to repo 3 during migration wizard repository selection step 5 of 9:


       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              hardeepn Hardeep Nagra
              Last Updated By:
              Peter Lynch Peter Lynch
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Date of First Response:

                  tigCommentSecurity.panel-title