In the last post, I started talking about how to discover the resources of a given software solution. In that post, I mentioned that one way to discover these resources is by inspecting architecture diagrams. It is important to stress the fact that these architecture diagrams only provide coarse-grained, not fine-grained, resources. Determining fine-grained resources and corresponding parameters is essential for performance and resiliency tuning and for checking if a solution is likely to have a resiliency problem under certain conditions.

In this post, I will provide other ways to discover the resources of a given solution. Note, however, it takes more work to discover these resources with the mechanisms discussed here.

Java Thread Dumps

As the title implies, this is specific to solutions written in Java. Whether you have a Java Standard Edition or a Java Enterprise Edition solution, Java provides a nice mechanism to take a snapshot of threads that exist inside the JVM. Although thread dumps provide a wealth of useful information for troubleshooting performance and resiliency issues, they have the following limitations when it comes to discovering solution resources:

1. If a solution has Java and non-Java components, the thread dump mechanism can reveal resources referenced or used inside the Java Virtual Machines (JVMs), but not inside non-Java resources. For example, the thread dump can tell us if a connection pool is used and what type of a connection pool the application is using. The thread dump can tell us if the connection pool is JDBC, JMS, or any other kind. But, the thread dump will not necessarily provide the name of the referenced or used resource. For example, the thread dump will not provide the name of the connection pool. This is a problem if you have more than one connection pool of a given type. However, the name of the thread pool and the thread ID used to execute a request will be clearly identified in the thread dump (this is true for IBM JDKs). Getting the names of the other resources referenced or used inside a JVM will have to be done using other means.
2. The thread dump is a snapshot of the threads that currently exist in the JVM. So, threads that may have executed before or threads that will execute after the thread dump is generated will not show up in the thread dump. This is important because the threads that may have executed before or threads that will execute after the thread dump is generated may identify additional resources. So, to identify as many resources as possible, taking thread dumps at regular intervals is one way to do it. But, this is still not a guarantee that all resources will be identified. For example, one transaction that uses a unique set of solution resources may run only once a day in the early AM. So, if you are taking thread dumps in the afternoon, you will not be able to identify the resources associated with this transaction, no matter how many thread dumps you take.

Execution Trace

This is a powerful method for identifying solution resources. If the software solution is developed with tracing capabilities where every resource access can be traced, then, this is a nice way to turn on the trace on demand and get the resource information from the trace. However, the trace generally has the following limitations:

1. It is used in a production environment only in a very limited way. In production, this method is usually used based on instructions of the middleware vendor support or services organization to look into a very specific area of a component or sub-component. This is done to confirm or discover a product defect in the middleware software.
2. The trace can be very verbose and can consume disk space very quickly. It is not uncommon for a trace to consume 100 MB or more of disk space in seconds. The more verbose the trace is, the more likely that a negative performance impact will result.