Search Images Maps Play YouTube News Gmail Drive More »
Advanced Patent Search | Page images | Web History | Sign in

Patents

  

mi iiiiiii ill mi mi iiiyiiijj|i ijii i|i mi linn mi mi mi

(12) United States Patent

Chagoly et al.

(io) Patent No.: (45) Date of Patent:

US 7,424,720 B2 Sep. 9, 2008

[blocks in formation]

5,537,548 A * 7/1996 Fin et al 709/204

5,706,429 A 1/1998 Lai et al 395/200.01

5,987,250 A * 11/1999 Subrahmanyam 717/130

6,108,619 A 8/2000 Carter et al 704/9

6,161,200 A * 12/2000 Reesetal 714/38

6,186,677 Bl* 2/2001 Angel et al 717/118

6,314,558 Bl* 11/2001 Angel et al 717/118

6,327,700 Bl* 12/2001 Chenetal 717/127

6,792,460 B2* 9/2004 Ouluetal 709/224

2002/0129337 Al* 9/2002 Evans et al 717/124

2002/0143933 Al 10/2002 Hindetal 709/224

2003/0149960 Al * 8/2003 Inamdar 717/118

2003/0217094 Al 11/2003 Andrews et al 709/201

2005/0039171 Al* 2/2005 Avakian et al 717/127

2005/0039172 Al* 2/2005 Reesetal 717/130

2005/0039186 Al * 2/2005 Borkan 719/310

[blocks in formation]
[blocks in formation]

8 Claims, 2 Drawing Sheets

[merged small][merged small][merged small][merged small][graphic][merged small][merged small][merged small][merged small][merged small][merged small][merged small][table][merged small][merged small][merged small]
[merged small][merged small][merged small][graphic][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][table][graphic][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small]
[merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][table][merged small][merged small][merged small][merged small][merged small][merged small][table][merged small][merged small][merged small][merged small][graphic][merged small][table][merged small][merged small][table][merged small]

1

PROCESS AND IMPLEMENTATION FOR
DYNAMICALLY DETERMINING PROBE
ENABLEMENT USING OUT OF PROCESS
CORRELATING TOKEN

5

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to an improved data processing system and, more specifically, to a method, appa- io ratus, and computer instructions for dynamically determining probe enablement using out of process correlating tokens.

2. Description of Related Art

Performance monitoring is often used in optimizing the use of software in a system. A performance monitor is generally 15 regarded as a facility incorporated into a processor to assist in analyzing selected characteristics of a system by determining a machine's state at a particular point in time. One method of monitoring system performance is to monitor the system using a transactional-based view. In this manner, the performance monitor may access the end-user experience by track- 20 ing the execution path of a transaction to locate where problems occur. Thus, the end user's experience is taken into account in determining if the system is providing the service needed. The performance monitor used may be any suitable transaction-based monitoring system, such as, for example, 25 IBM Tivoli Monitoring and Transaction Performance, a product of International Business Machines Corporation in Armonk, N.Y.

A number of performance monitoring tools have been developed to monitor and analyze the performance of appli- 30 cations within a system. As Java continues to become the Internet's dominant programming environment, Java applications are becoming increasingly more prevalent as the type of application used to support server and client computers. Java applications are also becoming more increasingly com- 35 mon in intranets and in other types of networks used in businesses.

Java is an object oriented programming language and environment focusing on defining data as objects and the methods that may be applied to those objects. Java supports only a single inheritance, meaning that each class can inherit from 40 only one other class at any given time. Java also allows for the creation of totally abstract classes known as interfaces, which allow the defining of methods that may be shared with several classes without regard for how other classes are handling the methods. 45

The Java virtual machine (JVM) is a virtual computer component that resides only in memory. The JVM allows Java programs to be executed on a different platform as opposed to only the one platform for which the code was compiled. Java programs are compiled for the JVM. In this manner, Java is 50 able to support applications for many types of data processing systems, which may contain a variety of central processing units and operating systems architectures. To enable a Java application to execute on different types of data processing systems, a compiler typically generates an architecture-neu- 55 tral file format—the compiled code is executable on many processors, given the presence of the Java run-time system. The Java compiler generates bytecode instructions that are non-specific to a particular computer architecture. A bytecode is a machine independent code generated by the Java compiler and executed by a Java interpreter. A Java interpreter 60 is a part in the JVM that alternately decodes and interprets a bytecode or bytecodes. These bytecode instructions are designed to be easy to interpret on any computer and easily translated on the fly into native machine code.

A known method of monitoring system performance is to 65 insert probes into the bytecode to help identify performance bottlenecks occurring within a transaction. Existing perfor

mance monitoring tools may also be used to link user transactions and sub-transactions using correlating tokens, such as ARM (Application Response Measurement) correlators. Correlating tokens are passed in user transactions to allow for monitoring the progress of the user transactions through the system. As an initiator of a transaction may invoke a component within an application and this invoked component can in turn invoke another component within the application, correlating tokens are used to "tie" these transactions together. For example, when a user invokes component A within an application, a transaction is created. Component A may call component B asynchronously to request that component B perform a specific process of the user transaction. Component A passes a unique correlating token with the call. When component B sends the response to component A, component A must be able to determine that the response correlates to the call. Thus, when component B finishes the invoked service, component B calls component A and passes back the original token. This process allows component A to correlate the request and the response.

Problems related to linking user transactions and subtransactions may occur when a sub-transaction occurs out of process of the initial user transaction. Although known performance monitoring tools provide mechanisms for monitoring applications to identify system bottlenecks, none of these known tools employ bytecode inserted probes to link crossprocess or cross-thread sub-transactions into a single user transaction. Using a Java 2 Platform Enterprise Edition (J2EE) transaction in a WebSphere Application Server as an example, if two or more WebSphere processes exist (which may or may not be running on different physical machines) and one process requests a method invocation from an Enterprise Java Bean (EJB) in a second WebSphere process, this unique user transaction should be linked and correlated across both WebSphere processes. Websphere applications, such as WAS, are available from International Business Machines Corporation. WAS is a J2EE application server that provides an operating environment for e-business applications that perform transactions over the internet.

Therefore, it would be advantageous to have a method, apparatus, and computer instructions for linking cross-process or cross-thread sub-transactions, using any given means of passing a correlating token to another process, into one user transaction.

SUMMARY OF THE INVENTION

The present invention addresses the problem of linking cross-process and cross-thread subtransactions into a single user transaction. The mechanism of the present invention employs bytecode inserted probes to dynamically detect out of process correlating tokens in an inbound request. The bytecode inserted probes retrieve the correlating token in the inbound request. Based on the correlating token retrieved, the bytecode inserted probes are then used to dynamically determine if the inbound user request should be recorded and linked to a transaction that began in another thread or process.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further obj ectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

FIG. 1 is a diagram of a distributed data processing system in which the present invention may be implemented;

« PreviousContinue »