If you need to update Oracle WebLogic 10.3.6 on Solaris / UNIX / Linux with a security patch or service pack, you will likely find yourself using the Oracle Smart Update program.
This program, which is run by executing the script bsu.sh, is usually found in the utils/bsu folder underneath the BEA Home folder. For example, if your BEA Home folder is “/u01/app/bea64/middleware”, you would change directory to “/u01/app/bea64/middleware/utils/bsu”, and execute bsu.sh, after uploading the required patch files to the cache_dir directory.
{user@server:/:}# cd /u01/app/bea64/middleware/utils/bsu
{user@server:/u01/app/bea64/middleware/utils/bsu:}# ./bsu.sh
Officially, this is how you would execute the program. Except that, for whatever reason, it seems that this script has not provided nearly enough memory for the program to run. Unfortunately, you will likely not find this out for almost an hour, while you get the splash screen above and your server attempts to run the program.
After the interminable wait is up, your program has crashed, and you finish pulling what’s left of your hair out, you can begin to troubleshoot the problem. Or, hopefully, you will have found this post before trying any of this!
Let’s look at the source of the problem. Literally.
{user@server:/u01/app/bea64/middleware/utils/bsu:}# cat bsu.sh
#!/bin/sh
JAVA_HOME="/usr/jdk/instances/jdk1.8.0"
MEM_ARGS="-Xms256m -Xmx512m"
"$JAVA_HOME/bin/java" ${MEM_ARGS} -jar patch-client.jar $*
{user@server:/u01/app/bea64/middleware/utils/bsu:}#
See that MEM_ARGS variable? This isn’t 1999 anymore, so let’s change the memory allocation, shall we? Oh, I should mention that if you’re still using a 32-bit version of Java, you’ll be constrained by that pesky 2 GB limit and will have to adjust accordingly.
Let’s see how much memory we have. I’m running Solaris, so this is what I ran:
{user@server:/u01/app/bea64/middleware/utils/bsu:}# prtconf | grep Memory
prtconf: devinfo facility not available
Memory size: 131072 Megabytes
{user@server:/u01/app/bea64/middleware/utils/bsu:}#
Also, I ran “java -d64” just to ensure that I am indeed running a 64-bit JVM.
Using everyone’s favorite editor (vi, of course), I increased the JVM memory allocations and saved the script as a new file: bsumem.sh.
#!/bin/sh
JAVA_HOME="/usr/jdk/instances/jdk1.8.0"
MEM_ARGS="-Xms32255m -Xmx64510m"
"$JAVA_HOME/bin/java" ${MEM_ARGS} -jar patch-client.jar $*
After saving the file, I executed it: “./bsumem.sh”
At this point, go pop some popcorn and watch an episode of something on Netflix or Amazon Prime. Don’t worry, the program will still be loading when you finish. (You might actually want to check every 15 minutes or so just to make sure that no other errors crashed the app!)
Once your show is over, you can come back and if you held your mouth right when executing the last command, the program will be ready to load the patch. Or you may have to wait another 15-20 minutes, but it should be relatively soon.
I have yet to figure out why this program takes so long to run, though from what I’ve read, it’s a common – if not universal – experience.
