WebLogic Diagnostics Framework-A Very Useful Tool

0

How many times have you looked at log files, searching, scanning, paging, over and over again looking for that one specific error that might help you solve your problem? If you’re like me, you’ve probably spent years doing this the old fashioned way in UNIX with the ‘more’ command. Or, maybe even the ‘tail’ command - endlessly looking at files until your eyes are sore and red! Well, the solution to our problem is finally here in version 11g. It’s called the WebLogic Diagnostics Framework (WLDF). It is a monitoring and diagnostic framework that defines and implements a set of services that run within WebLogic Server processes and participate in the standard server life cycle. Using WLDF, you can create, collect, analyze, archive, and access diagnostic data generated by a running server and the applications deployed within its containers. This data provides valuable insight into the run-time performance of servers and applications and enables you to isolate and diagnose faults when they occur.

In performance tuning a Java application, I recently used this tool while trying to find database connection leaks. I applied the Diagnostic Image Capture component of the WLDF to pinpoint where in their Java code they might not be closing database connections. I did this by executing a WebLogic Script from the command line:

java weblogic.Admin -adminurl t3://localhost:7001 -username weblogic -password Welcome1 GET -pretty -mbean "Mydomain:Location=Myapplicationname,Name=Mydatasourcename,ServerRuntime=Myservername,Type=JDBCConnectionPoolRuntime"

The script gave me an output that I could easily understand and read, informing me that there was problem In the Java Code:


        ActiveConnectionsAverageCount: 2
        ActiveConnectionsCurrentCount: 1
        ActiveConnectionsHighCount: 12
        CachingDisabled: true
        ConnectionDelayTime: 139
        ConnectionLeakProfileCount: 0
        ConnectionsTotalCount: 25
        CurrCapacity: 25
        DeploymentState: 2
        Enabled: true
        FailuresToReconnectCount: 0
        HighestNumAvailable: 25
        HighestNumUnavailable: 12
        LeakedConnectionCount: 3968
        MaxCapacity: 500
        ModuleId: Mydata
        Name:My data
        NumAvailable: 24
        NumUnavailable: 1
        Parent:MyContainer
        PoolState: true
        Properties: user=Scott
        Registered: true
        State: Running
        StatementProfileCount: 0
        Type: JDBCConnectionPoolRuntime
        VersionJDBCDriver: oracle.jdbc.xa.client.OracleXADataSource
        WaitSecondsHighCount: 0
        WaitingForConnectionCurrentCount: 0
        WaitingForConnectionHighCount: 0

Once I was able to determine that there were in fact connection leaks in the code (see LeakedConnectionCount above). I could then use the Diagnostic Image Capture component of the WLDF to create a snapshot in time and dig deeper into where this was happening. Using the WebLogic Server Console, in the Domain Structure, you simply navigate to the Diagnostics -> Diagnostics Images. Select the Managed Server you wish to capture an image for and click on the ‘Capture Image’ button. When the status has changed to ‘Completed’, you can change directories on the server to where that .zip file was created and copy that .zip file to another directory location to unzip it and analyze the files that were created as a result of the image capture.

diagnostics_thumb.png

In my particular case, I was interested in the JDBC.img file listed above. This file had the Java exceptions I was looking for and helped me locate the JSP that was causing the problem:

Resource Pool:MyData:dumpPool dumping reserved resources, #entries = 1
Resource Pool:MyData:dumpPool dumping reserved[0] = autoCommit=true,enabled=true,isXA=true,isJTS=false,vendor=0connUsed=false,destroyed=false,poolname=Mydata,appname=null,moduleName=null,connectTime=1-5,dirtyIsolationLevel=false,initialIsolation=false,lastSuccessfulConnectionUse=1343233471803,secondsToTrustAnIdlePoolConnection=10,currentUser=java.lang.Exception
at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.jaba:318)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.javaL344)


at jsp_servlet.<jspfile>.<JSPService>(__JSPMessage.java:153)


Because the diagnostic image capture is meant primarily as a post-failure analysis tool there is little control over what information is captured.  Available configuration options are:

  • The destination for the image;
  • For a specific capture, a destination that is different from the default destination;
  • A lockout, or timeout period to control how often an image is taken during a sequence of server failures and recoveries;
  • WLDF diagnostics volume, which determines the volume of WebLogic Server event information that is captured in the Flight Recorder file.

You can configure Diagnostic Image Capture using the Administration Console, the WebLogic Scripting Tool (WLST), or programmatically.

If the WebLogic Server is configured with Oracle JRockit, and the JRockit Flight Recorder is enabled, JRockit Flight Recorder data is automatically also captured in the diagnostic image capture. This data can be extracted from the diagnostic image capture and viewed in JRockit Mission Control. If JRockit Flight Recorder is not enabled, or if WebLogic Server is configured with a different JVM, the Flight Recorder data is not captured in the diagnostics image capture.

The WebLogic Diagnostic imaging capabilities are available in WebLogic Enterprise Edition and WebLogic Suite Edition. To read more about the WebLogic Diagnostics Framework and Diagnostics Image Capture in the 10.3.6 (11g) release, visit Oracle’s documentation online Configuring and Capturing Diagnostic Images.
 

Comments

No comments yet

Leave a Comment