• Get application security done the right way! Detect, Protect, Monitor, Accelerate, and more…
  • There are plenty of configuration options in IBM WAS through Admin Console but not all of them you need to touch.

    However, there are specific configurations you must be aware as a WebSphere administrator.

    The following 15 configurations are often touched or asked in an interview.

    If you are a beginner, I strongly you recommend you go through my previous two articles.

    WebSphere Application Server ND Installation Guide

    Useful WebSphere Application Server Administration Scripts

    So let’s get it started.

    1. Enable/disable Core Group services

    If you intend to use high availability manager service or just wish to know how to enable or disable Core group services and startup.

    To do this for Deployment Manager

    • Navigate to System administration >> Deployment manager
    • Click on Core group service under Additional Properties

    Here you can enable or disable the core group services

    core-group-services

    • Click on OK >> Synchronize Changes with Nodes >> Save

    To do this for JVM

    • Navigate to Servers>>Server Types>>WebSphere Application Server
    • Click on desired JVM
    • Click on Core group services under Additional Properties, and here you can enable/disable or modify the alive timer.
    • Click on OK >> Synchronize Changes with Nodes >> Save

    2. Configure log rotation, file size & historical log files

    If you are working on a production where resources are limited, and you want to keep your environment healthy and clean, you must be familiar with logs housekeeping.

    This will help you in housekeeping of SystemOut.log & SystemErr.log files.

    To do this for JVM

    • Navigate to Servers>>Server Types>>WebSphere Application Server
    • Click on desired JVM
    • Click on Logging and tracing under Additional Properties
    • Click on JVM Logs from the list

    To configure the maximum single log file size, you can enter the value in “Maximum Size.” In this ex, I have given 100 MB (by default it’s configured with 1 MB).

    To configure the log rotation period, you click on the checkbox for “Time” and enter the period you want to rotate the DMGR logs. In this ex, I have left it to default 24 hours.

    To keep the number of historical log files, you can enter the value in “Maximum Number of Historical Log Files. The number in a range of 1 through 200.” In this ex, I have given 30, which will keep 30 log files all the time.

    Repeat the same configuration for SystemErr.log. Here is the screenshot of above configuration.

    was-logging-tracing

    To do this for Deployment Manager 

    You can do this similar configuration for DMGR by navigating to Deployment Manager and follow the above steps to configure logging.

    3. Running JVM in development mode

    If you have installed WAS in production mode and there is a situation to run as development mode for troubleshooting, debugging or requested by development team – you can run particular WAS JVM in development mode by following.

    • Navigate to Servers>>Server Types>>WebSphere Application Server
    • Click on desired JVM
    • Tick the checkbox to run in development mode

    jvm-development-mode

    As usual, click on OK to Sync and Save the configuration.

    4. Configure Session Timeout & Cookie name

    WAS JVM default’s session timeout is set to 30 minutes, however, if you need to change you may do it by following.

    • Navigate to Servers>>Server Types>>WebSphere Application Server
    • Click on desired JVM
    • Click on Session management under Container Settings
    • Enter the desired value in minutes for “Session timeout:”

    By default cookie name is JSESSIONID and in case you need to modify you can do it by following.

    • Navigate to Servers>>Server Types>>WebSphere Application Server
    • Click on desired JVM
    • Click on Session management under Container Settings
    • Click on Enable Cookies
    • Enter the custom cookie name and click OK to Sync and Save the configuration.

    jvm-session-cookie-name

    5. Configure JVM’s heap size

    The necessary configuration for WebSphere administrator to know how to change JVM heap size, enable verbose garbage collection, configures Classpath/Boot Classpath.

    These all three configurations are done on a single page by:

    • Navigate to Servers>>Server Types>>WebSphere Application Server
    • Click on desired JVM
    • Click on Process definition under Java and Process Management
    • Click on Java Virtual Machine under Additional Properties

    6. JVM Heap Size Configuration

    Enter a value in “Initial heap size” for minimum memory and “Maximum heap size” for maximum memory size. In this ex – I have configured 2 GB as min and max.

    jvm-heap-size

    You may also refer to my detailed article on how to modify WAS JVM memory.

    7. Enable Verbose garbage collection

    To print garbage collection in verbose mode, you can tick on the checkbox for “Verbose garbage collection.” By default it’s disabled.

    jvm-verbose-gc

    8. Configure Classpath/Boot Classpath

    To configure classpath/boot classpath for particular JVM, you can enter the jar details to be loaded as the classpath. Mostly development team would recommend it.

    jvm-classpath

    Don’t forget to Sync & Save the configuration and restart the JVM to see the effects.

    9. Disable JVM Automatic restart (Monitoring Policy)

    By default, JVM will be restarted if it’s found in “STOPPED” mode. This is good and bad both.

    Good: there will be minimum service interruption/outage as JVM will be restarted automatically, so it saves your time in login into the server and starts the time.

    Bad: you don’t know why JVM was stopped you may overlook potential production issue.

    If you decide to disable automatic restart then you can do by following:

    • Navigate to Servers>>Server Types>>WebSphere Application Server
    • Click on desired JVM
    • Click on Monitoring Policy under Java and Process Management
    • Un-tick the checkbox for “Automatic restart.”

    disable-jvm-autorestart

    Click on OK to Save & Sync the configuration

    10. Enable & Configure Access Logs (NCSA)

    It may not be necessary to enable access logs for all the JVM’s, but I feel you can do this for DMGR, as you might be interested in reviewing the HTTP logs for access control. To enable this in DMGR: –

    • Navigate to System administration >> Deployment manager
    • Click on Logging and tracing under Additional Properties
    • Click on NCSA access and HTTP error logging from the list
    • Tick the checkbox for “Enable logging service at server start-up.”

    On this page, you can also configure a number of historical files to be kept, and maximum access log size. In this ex – I have configured 50 MB as file size and ten maximum numbers of files.

    dmgr-ncsa-log

    11. Change JVM logging level

    By default, JVM logging level is configured in “info” mode. However, if you wish to change to a warning or debug for troubleshooting purpose, you can do by following.

    • Navigate to Servers>>Server Types>>WebSphere Application Server
    • Click on desired JVM
    • Click on Change log detail levels
    • Change from info to the desired level. In this ex – I have configured debug level.

    was-log-level

    Note: this will write excessing logs hence you may configure debug for particular components by expanding “Components and Groups” and selecting the respective components.

    12. Change WebContainer thread pool

    You may come across a situation to change the web container thread pool if you are working on performance tuning. This must be configured on individual JVM level.

    • Navigate to Servers>>Server Types>>WebSphere Application Server
    • Click on desired JVM
    • Click on Thread pools under Additional Properties
    • Click on WebContainer from the list
    • Enter the desired value in minimum and maximum size. You may also configure thread inactivity timeout here.

    thread-pool

    13. Change Context Root for Application

    You can change the context root for deployed application without re-deploying it. The procedure is straightforward and very useful if you decide to change the context root.

    • Navigate to Applications >> all applications
    • Select the application from the list
    • Click on “Context Root For Web Modules” under Web Module Properties
    • Enter the desired value and click on OK to sync and save the changes.

    context-root-was

    JVM must be restarted to take effects.

    14. Change Virtual Host for particular application

    If you are using custom virtual host and application is deployed on default one then you will have an error “Virtual Host to handle has not been defined.” Well, you can quickly change the virtual host by following:

    • Navigate to Applications >> all applications
    • Select the application from the list
    • Click on Virtual hosts under Web Module Properties
    • Select the desired virtual host from drop-down
    • Click on OK to sync and save the configuration. JVM restart is required to take effects.

    15. Create Virtual host

    WAS comes with three virtual hosts (admin, default & proxy). If you are using WAS environment for the single application, then the default should be sufficient.

    However, if you have multiple applications and would like to segregate them by virtual host you can create one by following: –

    • Navigate to Environment >> Virtual hosts
    • Click on New
    • Enter the desired virtual host name
    • Click on OK to Sync and Save the configuration
    • Once a virtual host is created, you must add URL, which you will be using to access applications.

    To do so

    • Go to newly created virtual host and click on Host Aliases
    • Click on New
    • Enter Host Name and Port
    • Click on OK to Sync and Save the configuration

    Above configuration is not the complete list but often used so if you are beginner this should give you a good idea about IBM WebSphere application server configuration.

    Take your career to the next level by learning cloud computing.