Skip to end of banner
Go to start of banner

Inner-Thread tracing (synchronous methods)

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 43 Current »

This page describes all problems, tasks and solution approaches regarding tracing of method invocations in the same thread.

Main topics

  1. How to access information about the current method in a reliable way?

  2. How to associate a called method with it's caller?
  3. How to collect and filter the invocation information without much overhead on the target application and network?
  4. Can the amount of data from the agent be reduced? Can it be aggregated?

Current solution (state)

(Previous solution approaches regarding this topic were already discussed in the master thesis.)

Currently the sequence sensor is implemented as a container, which collects all sensor data (e.g. from timer sensors) starting from an defined start point (execution of a predefined method).
This collected data is chronologically ordered, to allow to trace the invocation sequence.

Disadvantage:

This is not suitable for asynchronous methods.  


(Also see continues sending in IS advanced notes for better understanding)

New approaches / solution

Idea:

On each hook, the Id of the currentThread would be acquired. So it could be saved when an method was executed by what thread.
(How much overhead would this generate?)


Questions / Possible Problems

  1. Do we have to modify the ClassLoaders and therefore keep them thread safe? 
  2. Do we have to modify Java core classes?
  3.  Which JVM implementations (e.g Sun JVM/ Sun Open JVM/ BEA JRockit/ Kaffe) can Javassist instrument or can be used on? (Is Javassist really platform independent?)
  4. What when Javassist does not work on a JVM?
  5. How to handle cascaded methods, when some in the middle are not monitored? M1>>M2>>M3>> but M2 not instrumented.
From Braindumb in IS Advanced

Each thread has a unique number (per JVM) automatically assigned.

    • But threads can and - in fact are - reused. For example thread pools do not instantiate new threads, but instead pass different Runnable instances to the existing threads. Each different runnable is itself a different functionality. Thus the thread ID cannot be safely used for identification
  • No labels