WebSphere Issues


Difference between backupConfig and manageprofiles -backupProfile commands

Filed under: WebSphere Application Server, WebSphere Portal — Tags: — Ishtiaque @ 2:42 pm

The <profile_root>/bin/backupConfig backs up only config directory of a profile. But the <profile_root>/bin/manageprofiles -backupProfile command backs up all the directories of a profile that include config, installedApps, properties, logs and others directories.

Here’s syntax of both commands:

  • <profile_root>/bin/backupConfig

It will create a .zip file inside <profile_root>/bin/WebSphereConfig_yyyy-mm-dd.zip

  • manageprofiles -backupProfile -profileName profile1 -backupFile D:/backups/profile1_backup.zip

Note: You need to stop the server first before running the commands.


Encode passwords in property and response files using WebSphere utilities

Filed under: Security, WebSphere Application Server — Tags: , — Ishtiaque @ 9:20 am

You can run PropFilePasswordEncoder and ResponseFilePasswordEncoder utilities in WebSphere Application Server to encode the property and response file passwords.

Encode passwords in WebSphere property files:

USAGE:  PropFilePasswordEncoder  file_name  password_properties_list  [-Backup/-noBackup]

EXAMPLE: <was_home>/bin/PropFilePasswordEncoder  <profile_root>/properties/soap.client.props   com.ibm.SOAP.loginPassword  -Backup

Encode passwords in WebSphere response files:

USAGE: ResponseFilePasswordEncoder file_name  assword_keys_list  [-Backup/-noBackup]

EXAMPLE: <was_home>/bin/PropFilePasswordEncoder  <W-Setup>/installresponse.txt  wasAdmin.password  -Backup


Connection leak diagnostics in WebSphere Application Server

Filed under: Java, WebSphere Application Server — Tags: , — Ishtiaque @ 12:29 pm

– Poorly written applications often do not properly release database connections.

  • Forget to call connection.close().
  • Most often in the exception case.
  • Connections should be closed in a finally{} block.

– Orphaned connections only return to the pool after timeout.

  • Can cause a backup of new connections waiting for old connections to time out.
  • New connections that have waited too long throw a connectionWaitTimeoutException.

– Connection manager is instrumented to print stack traces when a connectionWaitTimeoutException occurs.

  • Enabled using trace stringWAS.j2c=finest

Applications can suffer from performance problems and even appear to “hang” if they do not close their connections properly. This is most often caused by developers not properly using the connection.close() method. To ensure that connections will be closed properly, they should be closed in a finally{} block.

WebSphere is smart enough to eventually time out orphaned connections and return them to the pool, but for an application that makes frequent use of database connections, this might not be enough. New connections can get queued up waiting for the database while old connections are waiting to be timed out. This can bring the application grinding to a halt, and you can see connectionWaitExceptions.

The connection manager has lower performance impact than connection manager tracing. When activated, it enables a connection manager wrapper that holds the stack trace of all getConnection() calls in a throwable object. When an exception is thrown due to waiting on a full connection pool, print stack traces of all open connections. This enables you to significantly narrow your search area when you look at the application’s source code to try and find the responsible code.

Connection leaks have traditionally been hard to diagnose because the error messages do not usually provide specific enough information about the source of the problem. Usually a source code review is needed to find points in the code where connections are not properly closed. The connection manager makes this task much easier.


Analyze javacore files – hung thread detection in WebSphere Application Server

Filed under: Java, WebSphere Application Server — Tags: , — Ishtiaque @ 12:02 pm


A javacore is a small diagnostic text file that is produced by the JVM. It contains a lot of vital information about the running JVM process. It provides a snapshot of all the running threads, their stack traces and the monitors (locks) held by the threads. It can be a key in detecting hang or deadlock conditions.

You can manually trigger javacore file either by OS (UNIX/Linux)) command kill -3 <JVM PID> or by using wsadmin commands that’s documented here https://websphereissues.wordpress.com/2012/07/16/generating-a-jvm-thread-dump-javacore-using-wsadmin-commands/

  • Take a few (at least three) snapshots of the JVM (about 2–3 minutes apart).
  • Analyze the javacore to see what different threads are doing in each snapshot.
  • Example: A series of snapshots where container threads are in the same method or waiting on same monitor or resource would be an indication of a bottleneck, hang, or deadlock.

Hung thread detection:

Hung threads can be hard to diagnose. They are often not noticed until many threads are hung resulting in a performance problem. Application threads can hang for a number of reasons, including infinite loops, deadlocks or inaccessible resources.
There is a component known as the ThreadMonitor that monitors the Web Container, ORB, and Async Bean thread pools for hung threads.

When a thread is suspected to be hung, then notifications are sent in three ways:

  • JMX notification for JMX listeners
  • PMI Thread Pool data is updated for tools like the Tivoli Performance Viewer
  • Message is written to the SystemOut log.

The thread monitor does not try to deal with the hung threads, it just issues notifications, so that the administrator or developer can deal with the issues.

  • When the thread pool gives work to a thread, it notifies the thread monitor.
  • Thread monitor notes thread ID and timestamp.
  • Thread monitor compares active threads to timestamps.
  • Threads active longer than the time limit are marked “potentially hung”.
  • Performance impact is minimal (< 1%)

How the thread monitor works:

  • The thread monitor architecture monitors Web container, ORB, and asynchronous bean thread pools. It’s enabled by default.
  • No action taken to kill the thread; only a notification mechanism
  • When a thread is suspected to be hung, a message is written to the server’sSystemOut.log
  • Example: thread monitor message

[7/15/08 15:03:11:502 EDT] 3c3b4e37 ThreadMonitor W WSVR0605W: Thread “Servlet.Engine.Transports : 0” (37c18e37) has been active for 68,839 milliseconds and may be hung. There are 1 threads in total in the server that may be hung.


Basics of wsadmin tool

Filed under: Scripts, WebSphere Application Server — Tags: , , — Ishtiaque @ 8:31 am

The WebSphere administrative (wsadmin) scripting program is a powerful, non-graphical command interpreter environment enabling you to run administrative operations in a scripting language. The wsadmin tool is intended for production environments and unattended operations. The wsadmin tool provides:

  • Scripting capabilities
  • Command-line administration

The wsadmin tool uses the Bean Scripting Framework (BSF), which supports a variety of scripting languages to configure and control your WebSphere Application Server installation. The wsadmin tool provides support for:

  • Python commands through Jython
  • Tcl commands through Java Command Language Jacl

Jython versus Jacl:

  • Jython is syntax is more natural to Java or C programmers and Jacl is suited for admins familiar with Tcl
  • Future investment and strategic direction will be focused on the Jython language and it has much better support in RAD and WAS console
  • Jacl is supported in V7 and below versions but no future development or enhancements for Jacl
  • Jacl-to-Jython (Jacl2Jython) conversion assist tool is available

The wsadmin launcher makes administrative objects available through language-specific interfaces. Scripts use these objects for application management, configuration, operational control, and communication with MBeans running in WebSphere server processes. Three modes are used to invoke wsadmin:

  • Interactively; wsadmin

Example: <was_root>/profiles/profile1/bin/wsadmin/wsadmin

  • Command line; wsadmin -c <command>

Example: <was_root>/profiles/profile1/bin/wsadmin -c print(AdminApp.list()) -lang jython

  • Script file; wsadmin –f <script_file>

Example: <was_root>/profiles/profile1/bin/wsadmin -f D:/scripts/script.py

You can use the wsadmin tool to perform the same tasks that you can perform using the administrative console. You can use the wsadmin tool to manage a WebSphere Application Server V7 installation. Examples of tasks include:

  • Start and stop deployment manager, nodes, application servers, enterprise applications, and clusters
  • Configure virtual hosts, JDBC providers, JMS resources
  • Create application servers
  • Create clusters and add members to a cluster

Administrative objects in wsadmin:

Five administrative objects perform different operations:

 1. AdminConfig object communicates with the Config Service in a WebSphere server to manipulate configuration data for a WebSphere installation. AdminConfig has commands to list, create, remove, display, and modify configuration data, as well as commands to display information about configuration data types.
Example: wsadmin> AdminConfig.list(“JDBCProvider”)

2. AdminControl object enables the manipulation of MBeans running in a WebSphere server process. The number and type of MBeans available to the scripting client depends on the server to which the client is connected.  If the client is connected to a Deployment Manager, then all the MBeans running in the Deployment Manager are visible, as are all the MBeans running in the Node Agents connected to this Deployment Manager, and all the MBeans running in the application servers on those nodes.
Example: wsadmin> AdminControl.getPort()

3. AdminApp object allows application objects to be manipulated, this includes installing, uninstalling, editing, and listing of enterprise applications.
Example: wsadmin> AdminApp.list()

4. AdminTask object enables the execution of available admin commands.
Example: wsadmin> AdminTask.listServers()
Benefits of using AdminTask:
– Provides more user friendly and task-oriented commands
– Runs simple and complex commands
– Commands grouped based on function
– Can be run in batch or interactive mode
– Can be run in connected or local mode

5. Help object provide general help information for the objects supplied by wsadmin for scripting: Adminconfig, AdminApp, AdminControl and Help. It also provide a means to obtain interface information about MBeans running in the system.
– print Help.AdminTask()
– print AdminTask.help(‘-commands’)
– print AdminControl.help(‘getPort’)

Important points to remember when using wsadmin:
When using wsadmin, remember the following important points:

  • Default language set during profile creation is Jacl that’s defined in <was_profile>/properties/wsadmin.properties, so you need to specify wsadmin -lang jython if you want to run individual jython commands
  • wsadmin commands are case-sensitive that’s why wsadmin -lang jython -c “admincontrol.getPort()” will not work
  • Running multiple commands in a script file is faster than running individual commands because a JVM process needs to be created every time when an individual command is run. That’s why wsadmin -f “script_file_name” is faster than individual commands with wsadmin -c
  • Saving configuration changes is a two-step process: The first step validates the changes and the the second step performs the save
  • Save periodically in the script file or interactive mode to persist configuration updates to existing objects AdminConfig.save()



Generate JVM thread and heap dump manually using wsadmin (Jacl) commands

Filed under: Java, WebSphere Application Server — Tags: , , — Ishtiaque @ 8:02 am
  • Run /<profile_root>/wsadmin command to connect to the server profile
  • set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
  • $AdminControl invoke $jvm dumpThreads
  • $AdminControl invoke $jvm generateHeapDump

The thread dump (javacore.txt) and heap dump (heapdump.phd) files would be created in /<profile_root> directory.



Map Java EE application security roles to groups in WebSphere Application Server

Filed under: Java, Scripts, WAS — Tags: , , — Ishtiaque @ 12:07 pm

Assume we have a Java web app in which we have two servlets Staff and Student. Staff servlet is suppose to be accessed by members of group All-Staff and Student servlet by members of All-student group. Those groups are defined in WebSphere Application repository.

  • Login to WAS admin console and install the app
  • Create a group All-Staff and create a few staff users in this group such staff1, staff2..
  • Create a group All-Student and create a few student uses in this group such as student1, student2..
  • Install the app and then start the app
  • Navigate to MyApp > Security role to user/group mapping
  • Map All Student role to All-Student group and All Staff role to All-Staff group

Here are the contents of the web.xml file:

<?xml version=”1.0″ encoding=”UTF-8″?>
<web-app id=”WebApp_ID” version=”2.5″ xmlns=”http://java.sun.com/xml/ns/javaee&#8221; xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xsi:schemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd”&gt;

<servlet-name>Student Servlet</servlet-name>
<servlet-name>Staff Servlet</servlet-name>

<servlet-name>Student Servlet</servlet-name>
<servlet-name>Staff Servlet</servlet-name>

<web-resource-name>Student Servlet</web-resource-name>
<url-pattern> /student</url-pattern>
<url-pattern> /servlet/StudentServlet/*</url-pattern>
<http-method> GET</http-method>
<http-method> POST</http-method>
<role-name> All Student</role-name>

<web-resource-name>Staff Servlet</web-resource-name>
<url-pattern> /staff</url-pattern>
<url-pattern> /servlet/StaffServlet/*</url-pattern>
<http-method> GET</http-method>
<http-method> POST</http-method>
<role-name>All Staff</role-name>

<role-name> All Student</role-name>
<role-name> All Staff</role-name>


Secure servers are only supported with IBM JRE 6.0 or above error in Eclipse IDE

Filed under: Java, WAS — Tags: , — Ishtiaque @ 11:48 am

After you install the plugin for IBM WebSphere Application Server V7.0 Developer Tools via Eclipse Market Place you may get the following error while adding the WAS v7.0 server in eclipse:

Secure servers are only supported with IBM JRE 6.0 or above. Use the IBM JRE from the product installation image.

In order to resolve that error you need to add the IBM JRE v6 into eclipse configuration file eclipse.ini file:



Create a free website or blog at WordPress.com.