Nexus Maven repository migration

I need to migrate a Nexus 2.14 Maven repository to Nexus 3.10.

Unfortunately the Nexus product doesn't care much about migrations... probably they believe that, once installed, their product is immovable, like a sick elephant.

With a Nexus 2.14 to Nexus 2.14 migration, the repository structure is so simple that you can do it with a rsync.
But Nexus 3.10 is a totally different beast.

Luckily there are people who wrote tools:


https://github.com/simpligility/maven-repository-tools



I have to migrate from http://localhost:8081/nexus/content/repositories/releases/ (Nexus 2.14) to http://localhost:8181/repository/releases/ (Nexus 3.10)

git clone https://github.com/simpligility/maven-repository-tools.git
cd maven-repository-tools
mvn package
java -jar maven-repository-provisioner/target/maven-repository-provisioner-1.3.2-SNAPSHOT-jar-with-dependencies.jar

java -jar maven-repository-provisioner/target/maven-repository-provisioner-1.3.2-SNAPSHOT-jar-with-dependencies.jar -s http://localhost:8081/nexus/content/repositories/releases/ -t http://localhost:8181/repository/releases/ -u admin -p admin123 -a org.pierre:pvjoinfacestest:war:1.0


tragically, the tool doesn't allow wildcards.... so you must know in advance the gav of ALL the artifacts you have to migrate.... my impression is also that the .war is not really uploaded!


I am trying this one https://github.com/DarthHater/nexus-repository-import-scripts

copy https://github.com/DarthHater/nexus-repository-import-scripts/blob/master/mavenimport.sh to my /home/centos/nexus214/sonatype-work/nexus/storage/releases folder, then run

./mavenimport.sh -r http://localhost:8181/repository/releases/ -u admin -p admin123

and it works!

BEA-110433 Unable to obtain ownership of the transaction log

If you see "BEA-110433 Unable to obtain ownership of the transaction log", then

<Jan 12, 2016 3:41:57 PM CET> <Error> <JTA> <BEA-110433> <Unable to obtain ownership of the transaction log.> 
<Jan 12, 2016 3:41:57 PM CET> <Critical> <JTA> <BEA-111009> <activateDeployments failed during initialization. Failing reason: 
weblogic.server.ServiceFailureException: Cannot get ownership of Transaction Log.  Make sure that the Transaction Recovery Migratable Service is migrated back to the current server before restarting it.

weblogic.server.ServiceFailureException: Cannot get ownership of Transaction Log.  Make sure that the Transaction Recovery Migratable Service is migrated back to the current server before restarting it.
                at weblogic.transaction.internal.TransactionRecoveryService.checkTransactionLogOwnership(TransactionRecoveryService.java:408)
                at weblogic.transaction.internal.TransactionRecoveryService.resume(TransactionRecoveryService.java:183)
                at weblogic.transaction.internal.TransactionRecoveryService.initialize(TransactionRecoveryService.java:443)
                at weblogic.transaction.internal.StartupClass.main(StartupClass.java:32)
                at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                Truncated. see log file for complete stacktrace
>

then check your transaction-log-jdbc-store in the config.xml, make sure it's the same datasource used by data-source-for-automatic-migration, the auto-migration-table-name should be ACTIVE_SINGLETON_SERVICES, then drop this table and build it again with

CREATE TABLE ACTIVE_SINGLETON_SERVICES (
SERVER VARCHAR2(150) NOT NULL,
INSTANCE VARCHAR2(100) NOT NULL,
DOMAINNAME VARCHAR2(50) NOT NULL,
CLUSTERNAME VARCHAR2(50) NOT NULL,
TIMEOUT DATE,
PRIMARY KEY (SERVER, DOMAINNAME, CLUSTERNAME)
) ;

The root cause of this issue is often that the WLS servers are killed by operators rather than being "gracefully shutdown" as recommended by Oracle. For instance this happens when the Server is in Overload condition and the Graceful Shutdown times out (by default after 120 s). Thanks to Carlo for the explanation.

Consensus-based server migration: caveat

I used to have a Database-based lease mechanism for Server Migration, but occasionally it was failing ("unable to contact DB", no clue why...) and the server would restart itself.
We changed to Consensus, hoping the network would be more robust. However, due to a network reconfiguration, some IPs were left undefined and the cluster broke:

<[ACTIVE] ExecuteThread: '37' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <f56960fb001bca18:-33f939f3:1413c1039a1:-8000-0000000000065ea0> <1380619475997> <BEA-000802> <ExecuteRequest failed
java.lang.AssertionError: Invalid state transition from failed to stable_leader.
java.lang.AssertionError: Invalid state transition from failed to stable_leader
        at weblogic.cluster.leasing.databaseless.ClusterState.setState(ClusterState.java:100)
        at weblogic.cluster.leasing.databaseless.ClusterState.setState(ClusterState.java:59)
        at weblogic.cluster.leasing.databaseless.ClusterFormationServiceImpl.leaderInitialization(ClusterFormationServiceImpl.java:318)
        at weblogic.cluster.leasing.databaseless.ClusterFormationServiceImpl.formClusterInternal(ClusterFormationServiceImpl.java:148)
        at weblogic.cluster.leasing.databaseless.ClusterFormationServiceImpl.timerExpired(ClusterFormationServiceImpl.java:339)
        at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
>

The issue is that once the network has been fixed, the cluster didn't recover and we had to restart the servers... however this could simply be because when we restart the server, the Virtual IP associated to each server is readded to the NIC (/sbin/ifconfig -addif). Instead of restarting the servers I should have tried to add the IP manually... one should really monitor continuously the availability of those IPs...

Consensus-based Whole Server Migration

I have a cluster with 2 MS

On both MS, tick "enable whole server migration", and select both machines as possible targets (you will need both, if you want to migrate your server back)

At cluster level, don't forget to switch to "Consensus" (the default is "Database"), and again to choose both machines as target (not sure why this double settings):

At this point, after a good restart of both MS, you will be able to migrate a MS from one machine to the other - this will shutdown MS from 310 and startup on 311:

The end result will be that both MS are running on the same machine:

You can now bring down the first machine for maintenance.

Be aware that, if your MS uses a Virtual IP, and WSM is enabled, whenever you migrate a MS the VIP will be removed from the Origin machine and added to the Target machine.


If you forget to enable consensus, you will get this error:
BEA-003109 Cluster osbpp4cl uses database as the migration basis but no data source for migration has been configured.