Sunday, June 15, 2014

Upgrading to WebLogic 12c (12.1.2 or 12.1.3) from 10.3.5 or 10.3.6

    If you are upgrading from an older 11g 10.3.5 or 10.3.6 version of WebLogic Server to the latest 12.1.2 (EE6) or 12.1.3 (EE6 + partial EE7) version - the following references may be of assistance.


You can run 2 WebLogic domains simultaneously by running them on different ports.  Put one of the domains on admin port 7001 and the 2nd on admin port 17001, managed server ports 7101/7201 and nodemanager port 5556.

Create a (non-TX with properties: "Supports Global Transactions" global TX with one-phase commit) datasource to (for example postgreSQL) to be used by JMS called "MWJMSds".
Create a JDBC persistent store for each migratable server - but you will only be able to use datasources that are completely non-transactional.  Turn off the checkbox on the DS to see it in the dropdown of the persistent store create page.
The following table should be created "MW1WLStore" using a MW1 and MW2 prefix but we get.

one or more registered update listeners reported activation problems. The following failures occurred: -- The following failures occurred: -- javax.naming.NameNotFoundException: While trying to lookup 'jms.MWJDBCDerbyDS2' didn't find subcontext 'jms'. Resolved ''; remaining name 'jms/MWJDBCDerbyDS2' javax.naming.NameNotFoundException: While trying to lookup 'jms.MWJDBCDerbyDS2' didn't find subcontext 'jms'. Resolved ''; remaining name 'jms/MWJDBCDerbyDS2'

Make sure you target the managed server - not the admin server

MW_ManagedServer_1 (migratable)

Create JMS servers and target the persistent store and managed server target

MW_ManagedServer_1 (migratable)

Create a JMS Module
Create a subdeployment - target only the 2 JMS servers
Create a JMS distributed queue - use advanced targeting and select the subdeployment.
Go back into the JMS queue | SubDeployment and notice that the subdeployment is reset to "none" - this seems to be a new bug in WebLogic - if you resave this page you will reset the subdeployment and target

Uniform Distributed Queue
JMSServer-1, JMSServer-2

If I deselect one of the JMS servers in the subdeployment setup page - then the subdeployment reappears on the subdeployment dropdown of the distributed queue.
Other possible workarounds like changing the target of the subdeployment to the cluster (which inherits the JMS server(s)) does not work.

There are many features not available in default targeting - therefore we need to get multi-server subdeployment working.

weblogic_timers table:
Verify that the datasource is set on the cluster | configuration | scheduling page



The server consists of a cluster where each physical node has a nodemanager, 2 managed servers and 2 JMS servers.

Design Issues

DI 1: JMS Server failover via Migratable Target

DI 2: Time for all managed servers and DB must be synchronized

Verification Test Plan:


Uniform Distributed Queues:
The documentation for 12.1.2 states that default targeting should be deferred in favour of advanced targeting involving subdeployments.
However there is an issue where the subdeployment that targets more than one JMS server is not selectable as a target for UDQ's.

Targeting the cluster instead of a subdeployment is very limited in functionality - therefore we need to get multi-server subdeployment working.

Cluster | Configuration | Singleton Services

JPA 2.0

Although JPA 2.0 has been available since the 15 Jan 2010 release of WebLogic 10.3.4 - upgrading from JPA 1.0 may experience the following issues.


Listen Address Unspecified:
The following warning means that multiple IP's are configured for the cluster
<Jun 15, 2014 8:10:48 PM EDT> <Warning> <Cluster> <BEA-003121> <Unicast cluster may not function correctly as the listen address of server MW_ManagedServer_1 is not specified.> 



Blogger said...

DreamHost is one of the best hosting provider for any hosting services you require.

Madhu N said...

Hey sorry to say this blog is not good

Total Pageviews