This page describes all problems, tasks and solution approaches regarding tracing of method invocations that can span over multiple threads.
Main topics
How to access information about the current method?
- How to handle asynchronous methods, that are still running after its parent are already terminated?
- How to tell the called method who is its caller or parent?
- How to find out the three points of interest in threads?
- How to tell, what thread created the current thread, what thread called it and what thread is executing it?
- How to handle thread pools?
- Is there a universal solution for every thread pool implementation?
Current solution (state)
(Previous solution approaches regarding this topic were already discussed in the master thesis.)
Currently the container approach is used, that does not support asynchronous method invocations.
In my understanding, asynchronous method invocation are in fact cached by the invocation sequence sensor(if instrumented), but are not displayed i the context tree in the right branch. There also ordered according to the invocation order.
New approaches / solution
Coming soon...
Questions / Possible Problems
- An asynchronous method invocation has no fixed start and end point. Is possible, that a asynchronous methods is still running after its caller is already finished.
- How can i modify the start() method on Threads, to get the information about the Thread creator, caller and executor?
From brain dump
To build up an invocation sequence, each invoked method must know the method that was invoked before it
- Innerthread communication can simply make use of the ThreadLocal pattern and build a stack of the concrete methods being called
- Interthread and inter JVM communication has to connect the stacks of the involved threads. This can be done by an invocation identifier that is passed from the caller to the callee. (see previous solution approaches)
- Invocation identifier must also include the method identification that invoked this call