ORA-01017: invalid username/password; logon denied when updating WebLogic data source and you know the username and password are correct

Background

The title might sound a bit confusing, because everyone that has experienced an ORA-01017 knows it only happens if either the database username or password is incorrect.

I recently had to change the password for all of the infrastructure component schemas in a Oracle® SOA Suite 12.1.3 installation. How to do it is documented at https://docs.oracle.com/middleware/1213/core/ASADM/repos.htm#ASADM637

After running the modifyBootStrapCredential for the OPSS configuration I expected everything to be dandy except a few ORA-01017 errors for the data sources I had not yet updated with the new password. Everything I needed to do was to edit each data source and provide the new password. Or so I thought...

The problem

When I tried to apply the changes I got the following ORA-01017 error for each data source I tried to edit:

I was a bit thunderstruck at first because the username and passwords worked fine in both SQL*Plus and in SQL Developer.

The AdminServer out file contained errors like this:
<Jan 19, 2016 1:15:54 PM UTC> <Error> <Deployer> <BEA-149205> <Failed to initialize the application "LocalSvcTblDataSource" due to error weblogic.application.ModuleException: weblogic.common.resourcepool.ResourceSystemException:
 Could not create connection for datasource '<data source name>'.

 The returned message is: ORA-01017: invalid username/password; logon denied

 It is likely that the login or password is not valid.
 It is also possible that something else is invalid in
 the configuration or that the database is not available.
weblogic.application.ModuleException: weblogic.common.resourcepool.ResourceSystemException:
 Could not create connection for datasource '<data source name>'.

 The returned message is: ORA-01017: invalid username/password; logon denied

 It is likely that the login or password is not valid.
 It is also possible that something else is invalid in
 the configuration or that the database is not available.
        at weblogic.jdbc.module.JDBCModule.prepare(JDBCModule.java:350)
        at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:100)
        at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:175)
        at weblogic.application.internal.flow.ModuleStateDriver$1.next(ModuleStateDriver.java:170)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
        Truncated. see log file for complete stacktrace
Caused By: weblogic.common.resourcepool.ResourceSystemException:
 Could not create connection for datasource '<data source name>'.

 The returned message is: ORA-01017: invalid username/password; logon denied

 It is likely that the login or password is not valid.
 It is also possible that something else is invalid in
 the configuration or that the database is not available.
        at weblogic.jdbc.common.internal.JDBCUtil.parseException(JDBCUtil.java:322)
        at weblogic.jdbc.common.internal.ConnectionEnvFactory.makeConnection0(ConnectionEnvFactory.java:492)
        at weblogic.jdbc.common.internal.ConnectionEnvFactory.access$000(ConnectionEnvFactory.java:20)
        at weblogic.jdbc.common.internal.ConnectionEnvFactory$1.run(ConnectionEnvFactory.java:388)
        at java.security.AccessController.doPrivileged(Native Method)
        Truncated. see log file for complete stacktrace
>

The workaround

For each data source I had to do the following to work around this problem:

1. Clicked the Lock & Edit button.
2. Had to note which targets the data source was using.
3. Removed the targets from the data source, and clicked on the Save button.
4. Clicked on the Activate Changes button.
5. Clicked the Lock & Edit button.
6. Updated the password for the data source, and clicked on the Save button.
7. Clicked on the Activate Changes button.
8. Clicked the Lock & Edit button.
9. Added the targets that I noted in step 2 to the data source, before I clicked on the Save button.
10. Clicked the Activate Changes button.

After all data sources had been updated with the new passwords, and the data sources had been re-targeted, I did a full domain restart. 

While I started the AdminServer up, I looked out for errors like these which could indicate I had forgotten to update some data sources:

<Jan 19, 2016 1:32:34 PM UTC> <Error> <Deployer> <BEA-149205> <Failed to initialize the application "<data source name>" due to error weblogic.application.ModuleException: weblogic.common.resourcepool.ResourceSystemException

How to find which Java thread on WebLogic that causes high CPU utilization on Linux

Scope

Sometimes your Linux server is having close to 100% CPU utilization. It is easy and quick to find which process is spending more CPU by running the top command. It takes a few more steps to establish which Java(TM) thread is using CPU, and what that thread is doing. This blog will explain the procedure for gather evidence to your developers that their code is too CPU intensive.

Scenarios

I have tried this procedure using the following versions of Oracle® WebLogic and Java(TM):

• Oracle® WebLogic 12.1.3 with Oracle® Java(TM) SE 7 - jdk1.7.0_79
• Oracle® WebLogic 10.3.6 with Oracle®Java(TM) SE 7 - jdk1.7.0_79
• Oracle® WebLogic 10.3.6 with Oracle® Java(TM) SE 6 - jdk1.6.0_45
• Oracle® WebLogic 10.3.6 with Oracle® JRockit(R) 6 - R28.2.7

These guidelines would also work on other servers using Oracle® Java(TM) SE.

Overview

The procedure for finding the most CPU intensive thread is basically the same for each combination of Oracle® WebLogic and Java(TM):

• Find the ID of the process that has highest CPU utilization
• Find the ID of the thread that has highest CPU utilization based on the process ID found above.
• Take a thread dump of the process based on the process ID found above.
• Search for the thread ID in the thread dump
• Identify the code that causes issues

Find the ID of the process that has highest CPU utilization

Use the top command and look at the CPU% column to identify which PID has highest CPU utilization. In the case below, the PID with 7253 uses most CPU%.

Find the ID of the thread that has highest CPU utilization based on the process ID found above

Again we can use the top command to find out which threads are spending most CPU% with the PID as input. The command will be:

top -H -p <PID>

Take a thread dump of the process based on the process ID found above

Use the jstack <pid> command with Java HotSpot(TM) or the jrcmd <pid> print_threads command with Oracle® JRockit(R) to get a thread dump. For instance:

$JAVA_HOME/bin/jstack 7253 > /tmp/stack.txt

Search for the thread ID in the thread dump file

Some tools will write the thread IDs as decimal numbers and others will write it as hexadecimal numbers. In this blog post I used Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode) which wrote the thread IDs as hexadecimal numbers. When testing Oracle® JRockit(R) however, my thread IDs were written with decimal numbers. 

From the list of thread IDs above, I converted the three thread IDs with highest CPU% to hex:

[oracle@localhost dom_12c_hotspot7]$ printf "%x\n" 7255
1c57
[oracle@localhost dom_12c_hotspot7]$ printf "%x\n" 7286
1c76
[oracle@localhost dom_12c_hotspot7]$ printf "%x\n" 7291
1c7b

I can now search for 1c57, 1c76 and 1c7b in the /tmp/stack.txt file I created.

Nothing exciting about 1c57 as it was only the "VM Thread":

The other thread ID 1c76 is coming from my custom code:

The third thread ID 1c7b is also coming from my custom code, and that thread is even STUCK.:

This was just an example on how to find threads with high CPU utilization. The code deployed was written poorly on purpose to cater for this article. Finding the performance issue on a real life application will probably prove to be more complex. In case there are multiple threads that fights over the CPU, then it is probably better to do live analyses using a tool like JVisualVM.

How to troubleshoot and fix "ORA-01882 timezone region not found" while creating WebLogic data source

Symptoms

While creating a data source in WebLogic you get the error "ORA-01882 timezone region not found" while saving the new configuration. 

Troubleshooting

This troubleshooting was performed on a Red Hat Linux 6.6 server running WebLogic 12.1.3

Finding the timezone used by the JVM

Even if the user account running WebLogic does not have a TZ environment variable set, the JVM will pickup a timezone as specified by the sysconfig clock on Linux. By running $JAVA_HOME/bin/jvisualvm you will be able to find out which timezone it is using by looking for the user.timezone property in System properties:

In my case this was originally set to Etc/UTC. 

Which timezones are supported by the Oracle database

Log on to the database to which you attempted to create a data source, and then run the following query:

SELECT * FROM V$TIMEZONE_NAMES ORDER BY 1;

In my case there was no such thing as TZNAME = Etc/UTC. But of course just UTC was a valid value. 

Force WebLogic to use UTC timezone

Edit $DOMAIN_HOME/bin/startWebLogic.sh and go to the bottom of the file where the commands to startup WebLogic reside. After each of the three ${MEM_ARGS} add -Dtimezone=UTC. After your change the section will look like this:

echo "starting weblogic with Java version:"

${JAVA_HOME}/bin/java ${JAVA_VM} -version


if [ "${WLS_REDIRECT_LOG}" = "" ] ; then

echo "Starting WLS with line:"

echo "${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} -Duser.timezone=UTC -Dweblogic.Name=${SERVER_NAME} -Djava.security.policy=${WLS_POLICY_FILE} ${JAVA_OPTIONS} ${PROXY_SETTINGS} ${SERVER_CLASS}"

${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} -Duser.timezone=UTC -Dweblogic.Name=${SERVER_NAME} -Djava.security.policy=${WLS_POLICY_FILE} ${JAVA_OPTIONS} ${PROXY_SETTINGS} ${SERVER_CLASS}

else

echo "Redirecting output from WLS window to ${WLS_REDIRECT_LOG}"

${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} -Duser.timezone=UTC -Dweblogic.Name=${SERVER_NAME} -Djava.security.policy=${WLS_POLICY_FILE} ${JAVA_OPTIONS} ${PROXY_SETTINGS} ${SERVER_CLASS} >"${WLS_REDIRECT_LOG}" 2>&1
fi

Finally restart WebLogic.

Verify that the JVM is using the new timezone

The quick way to check it is of course "ps -ef | grep timezone" and make sure there is one hit per managed server plus the AdminServer. 

Of you can check with JVisualVM as explained above.