The problem
After starting the Oracle® WebLogic AdminServer in a sandbox environment, I attempted to start the managed servers, but got the following errors in the $DOMAIN_HOME/servers/<ms-server>/logs/<ms-server>.out log file:
<Error> <Configuration Management> <BEA-150001> <An error occurred while connecting to the Administration Server to bootstrap through the URL: http://localhost:7001/bea_wls_management_internal2/Bootstrap,
user: weblogic.
weblogic.management.configuration.ConfigurationException: [Management:141252]The domain version 12.2.1.0.0 is greater than the release version 12.1.3.0 of this server.
at weblogic.management.provider.internal.BootStrapHelper.getBootStrapStruct(BootStrapHelper.java:147)
at weblogic.management.provider.internal.RuntimeAccessImpl.initialize(RuntimeAccessImpl.java:444)
at weblogic.management.provider.internal.RuntimeAccessService.start(RuntimeAccessService.java:70)
at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
The cause
I was at first a bit puzzled by the message "The domain version 12.2.1.0.0 is greater than the release version 12.1.3.0 of this server." because the AdminServer console footer said it was version 12.1.3.0, and the startup scripts in $DOMAIN_HOME/bin also only pointed to 12.1.3.0 binaries.
I discovered there were 12.2.1.0.0 binaries installed in a new $ORACLE_HOME, but as mentioned, these binaries were not referenced by the scripts in $DOMAIN_HOME/bin.
The fact that 12.2.1.0.0 binaries were available on the file system suggested someone had either planned to create a new 12.2.1.0.0 domain, or planned to upgrade the existing 12.1.3.0 domain.
After discussing this with a colleague it became clear that he had installed the new binaries, and that all he wanted to do with them was to create response files for running the upgrade of a domain on a different server. He only intended to run the information collection part, but it had obviously also touched the $DOMAIN_HOME/config/confix.xml file in the 12.1.3.0 domain, and changed the version parameter to 12.2.1.0.0 as shown below:
$ grep version $DOMAIN_HOME/config/config.xml
<?xml version='1.0' encoding='UTF-8'?>
<domain-version>12.2.1.0.0</domain-version>
<configuration-version>12.2.1.0.0</configuration-version>
I discovered there were 12.2.1.0.0 binaries installed in a new $ORACLE_HOME, but as mentioned, these binaries were not referenced by the scripts in $DOMAIN_HOME/bin.
The fact that 12.2.1.0.0 binaries were available on the file system suggested someone had either planned to create a new 12.2.1.0.0 domain, or planned to upgrade the existing 12.1.3.0 domain.
After discussing this with a colleague it became clear that he had installed the new binaries, and that all he wanted to do with them was to create response files for running the upgrade of a domain on a different server. He only intended to run the information collection part, but it had obviously also touched the $DOMAIN_HOME/config/confix.xml file in the 12.1.3.0 domain, and changed the version parameter to 12.2.1.0.0 as shown below:
$ grep version $DOMAIN_HOME/config/config.xml
<?xml version='1.0' encoding='UTF-8'?>
<domain-version>12.2.1.0.0</domain-version>
<configuration-version>12.2.1.0.0</configuration-version>
The solution
- Shutdown the entire domain. In my case that meant the AdminServer and the NodeManager.
- Took a file system backup of $DOMAIN_HOME
- Edited $DOMAIN_HOME/config/config.xml and replaced the two occurences of 12.2.1.0.0 with 12.1.3.0.0
- Started the NodeManager, the AdminServer and the managed servers up without any errors.
Post-change verification:
$ grep version config.xml
<?xml version='1.0' encoding='UTF-8'?>
<domain-version>12.1.3.0.0</domain-version>
<configuration-version>12.1.3.0.0</configuration-version>
No comments:
Post a Comment