IBM JVM and JDK -Xdump and -Xtrace options for scenario based problem determination

There are multiple ways of configuring the IBM JDK shipped by WebSphere Application Server to generate  WebSphere and JDK trace in situations where you have no control of the application or the server runtime.

Scenario 1: 
In a long running server when an exception occurs say a javax.transaction.RollbackException, we need to enable a particular WebSphere runtime trace for a period of 1 hour to collect pertinent logs. This allows for collection for logs ONLY and IF a critical incident occurs in long run and production deployment scenarios.

Using the JVM dump engine ability to run command lines based on events, you could trigger a command line on, say, the uncaught javax.transaction.RollbackException:
-Xdump:tool:events=uncaught.filter="javax/transaction/RollbackException",exec="command line to run"
Where we could then use wsadmin to change the trace settings:
exec="sh /opt/IBM/WebSphere/AppServer/bin/wsadmin.sh -lang jython -f setWASTrace.py"

For (setWASTrace.py) scripting with WebSphere Application Server see this blog post.

Scenario 2:
Print a thread stack trace whenever the method com.ibm.ws.util.ThreadPool$Worker.setStartTime method is called
-Xtrace:print=mt,methods={com/ibm/ws/util/ThreadPool$Worker.setStar tTime},trigger=method{com/ibm/ws/util/ThreadPool$Worker.setStartTime,jstack trace}

Scenario 3:
Print JVM entry and exit trace in clear text whenever any code is executed in the sun.net.www.protocol.http and sun.net.www.http packages
-Xtrace:methods={sun/net/www/protocol/http*,sun/net/www/http*},print=mt


Scenario 4
Take Javacores when CPU Starvation is detected. This will write to a file named cpu_starvation%pid%.txt in the current working directory of the JVM (i.e. the same directory as the javacores) when CPUStarvationDetectedException is thrown

-Xdump:tool:events=throw,range=1..0,filter=com/ibm/loglistener/CPUStarvationDetectedException,exec="cmd /c c:\cpu_starvation.bat end %pid" 

Scenario 5
Take java stack traces when multiple methods are fired. This is useful to determine the root cause of memory leaks if one method allocates an object (i.e. puts in a map) and other method releases the resource (removes the object from the map)

-Xtrace:trigger=method{com/ibm/ws/webbeans/services/JCDIComponentImpl.storeCreationalContext,jstacktrace} -Xtrace:trigger=method{com/ibm/ws/webbeans/services/JCDIComponentImpl.releaseCreationalContext,jstacktrace}