Abstract: Application data is reported in response to monitoring an application transaction. Application data is obtained for an initial period of time. A function which estimates the application data is then identified for the reported application data. After identifying the function, subsequent application data is obtained, and function data is generated from the subsequent application data. The function data may be associated with function parameters associated with the identified function. A function can then be constructed from the reported function data. The function constructed from the function data may estimate application data associated with the monitored transactions.

Abstract: Data relating to execution flows at a computer system is compressed and aggregated across multiple execution flows by categorizing each execution flow into an execution flow shape. The execution flows may represent sequences of software components that are invoked. The execution flow shapes are developed by observing the execution flows at the computer system and applying lossy compression rules, such as representing multiple iterations of a loop as a single iteration, skipping certain types of software components, such as those having a specified call stack depth, treating some of the software components as being optional, and ignoring recursive calls by the software components. The aggregation and compression allow the information from all execution flows to be combined into a small enough data set that can be reported without consuming unduly large processing overhead while still preserving as many of the interesting aspects of the execution flows as possible.

Abstract: Data relating to execution flows running on different processes or threads at a computer system is correlated. The execution flows may represent sequences of software components that are invoked or other computer system resources that are consumed. A first execution flow fulfills a first request by transmitting a second request which initiates a second execution flow, such as at another computer system. The second request includes meta data which identifies a context of the first request, such as a URL, an agent which monitors the first execution flow, and the component in the first execution flow which initiated the second request. A manager receives information regarding the first execution flow from the first agent, and information regarding the second execution flow, along with the meta data, from a second agent, for correlating the first and second execution flows. The received information may include execution flow shape data.

Abstract: Data relating to execution flows at a computer system is aggregated across multiple execution flows by categorizing each execution flow into an execution flow shape. The execution flows may represent sequences of software components that are invoked or other computer system resources that are consumed. The execution flow shapes are developed by observing and recording the execution flows at the computer system and applying lossy compression rules. Execution flows are categorized into an execution flow shape which is a closest match. The execution flow data may be aggregated by an agent at the computer system, and communicated to a manager for subsequent use. The aggregation combines the information from all execution flows into a small enough data set that can be reported without consuming unduly large processing overhead while still preserving as many of the interesting aspects of the execution flows as possible.

Abstract: A system is disclosed that can determine whether a routine is stalled. The system does not require the developer of the routine to add code for the purpose of detecting whether the routine is stalled. Furthermore, the system can be used to monitor various routines at different levels of granularity, such as at the thread level, method level, or other levels. One embodiment of the present invention allows a user to specify a method and an expected time frame. Code for that method is modified to add additional code that implements a timing mechanism. The timing mechanism is used to detect when a thread enters that method and does not return within an approximation of the expected time frame. Other embodiments are also within the scope of the present invention.

Abstract: The system receives three sets of inputs: program class definitions, a set of rules, and additional class definitions to be merged with the program class definitions. There are three types of rules: the first rule is used to substitute the allocation of an object of a new class for the allocation of the object based on an original class; the second rule is used to change code that allocates an object of an original class to code that calls a static method that allocates the object of the original class; and the third rule is used to a replace a new static field for an original static field. The system separately reads each of the original class definitions into a class data structure and performs the modifications to the class data structure according to the set of rules. The resulting class data structure is written to an output stream.

Abstract: The system receives three sets of inputs: program class definitions, a set of rules, and additional class definitions to be merged with the program class definitions. There are three types of rules: the first rule is used to substitute the allocation of an object of a new class for the allocation of the object based on an original class; the second rule is used to change code that allocates an object of an original class to code that calls a static method that allocates the object of the original class; and the third rule is used to a replace a new static field for an original static field. The system separately reads each of the original class definitions into a class data structure and performs the modifications to the class data structure according to the set of rules. The resulting class data structure is written to an output stream.