Monday, June 30, 2014

Right strategy to set startup (JVM+NON-JVM) arguments and debug flags in Weblogic Server

Note: This strategy is applicable in Oracle Weblogic Server, Oracle WebCenter Portal, Oracle SOA/BPM Suite, Oracle WebCenter Content and other Oracle products which are using Weblogic Server. 

Step-by-step guide
  1. Finalise the right way
    There are two options to configure the JVM arguments:
    1. Via the "Server Start" tab at Administration Console , which is equivalent to the <server-start/> tag in config.xml
    2. Via the script file( and under DOMAIN_HOME/bin/ of each server
    The problem of Option 1 is that the JVM parameters you put in <server-start/> via either Console or directly via config.xml will take effect only if you start the server from NodeManager. If you start the server via scripts, e.g.,, the parameters in <server-start/> in config.xml will be ignore.
    For Option 2, if you start servers via scripts under DOMAIN_HOME/bin, specifying JVM parameters will of course work. And as long as you set the StartScriptEnabled=true and, as required by the Enterprise Deployment Guide, starting servers via NodeManager will also call the same scripts, and hence will pick up the JVM arguments you set there. So you are covered both ways.
    I would go with Option-2 as its covered both ways (nodemanager and startup script), its easy to change via Hudson or manually, its less risky approach as compared to config.xml.
  2. Finalise the right script file
    Now, we have chose the right way to specify JVM arguments. Next step is right file to specify the arguments. There are following two files to specify the JVM arguments and non-JVM arguments:-
    2. is the right file to specify JVM arguments. This file is called by all startup script like and and nodemanager. Although, is also called by and nodemanager but is the more logical choice due to its purpose and name.
  3. Finalise the right variable
    After choosing the right file, next step is choosing the right variables. There are a lot of variables that are related to JVM arguments: MEM_ARGS, USER_MEM_ARGS, JAVA_OPTIONS, JAVA_PROPERTIES etc. Oracle recommend to use the JVM memory settings (i.e. max and min heap size, PermGen size, etc) via variables USER_MEM_ARGS, and specifying any other JVM arguments or non-JVM arguments via JAVA_OPTIONS.
    The advantages of using USER_MEM_ARGS:-
    1. It will override the all standard memory arguments passed to JAVA.
    2. It will reflect right parameters in the server startup logs.
  4. Finalise the right location in the script file
    It is important to specify the USER_MEM_ARGS in the right location of file. Following is the right location:-
    #IF USER_MEM_ARGS the environment variable is set, use it to override ALL MEM_ARGS values:-
    USER_MEM_ARGS="-server -Xms2g -Xmx2g -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseG1GC -XX:ParallelGCThreads=4"
    export USER_MEM_ARGS 
    if [ "$
    {USER_MEM_ARGS}" != "" ] ; then
    export MEM_ARGS
  5. Finalise the right way to specify the JVM arguments per server
    In such case you can script your JVM settings based on the server names in file like
    #In case of Admin Server
    if [ "${SERVER_NAME}" == "Admin_Server" ] ; then
    USER_MEM_ARGS="-Xms1024m -Xmx1024m"
    export USER_MEM_ARGS

    #if server name contains WLS_SERVER*
    if [[ "${SERVER_NAME}" == "WLS_SERVER*"]] ; then
    USER_MEM_ARGS="-server -Xms2g -Xmx2g -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseG1GC -XX:ParallelGCThreads=4"
    export USER_MEM_ARGS
  6. Other recommendations about better management
    a. To be safe, it is better to move the all custom arguments (JVM + NON-JVM) to an external script (e.g., and source this external script from file like:-
    #IF USER_MEM_ARGS the environment variable is set, use it to override ALL MEM_ARGS values
    . ${DOMAIN_HOME}/bin/
    if [ "${USER_MEM_ARGS}" != "" ] ; then
    export MEM_ARGS
        b. To easy to manage and easy to change, we can put the at a shared file system. So you keep only one copy of it where all the JVM settings are centralised. This single copy of can be referenced by the individual for each server.

All done. 

Monday, March 17, 2014

When we need a new Weblogic Domain?

Depending on your particular business needs and system administration practices, you might decide to organize your domains based on criteria such as:

  1. If you have different applications using the same set products  but their maintenance requirements (patching, backup etc) are different.
  2. If you have different applications using the different version of the Oracle WebLogic Server software (Weblogic, WebCenter Portal, IDM, SOA etc)
  3. Different System administrators are responsible to manage different applications due to physical location, or branches of your business.
  4. Different applications are using different LDAP providers and your top requirements are Performance and Security
  5. If you want to segregate domains according to product components (WC, SOA, WL etc) or physical tier [Presentation, Integration, Service, Data etc] to achieve better maintainability
  6. If you want to segregate domains according to logical divisions of applications. For example internet applications and intranet applications OR financial applications and portal applications.