This page contains the solution approaches that were discussed in the master thesis.
...
Method-ID approach
Quote:
"Another possibility to realize the invocation tracer is to add unique identifiers to all available sensors, so that every sensor gets an additional thread Id and a continuous node number in a call tree. This way, the process of building a complete Context Call Tree is divided in several parts: the sensors provide small pieces of information and some kind of tree builder has to provide a basic functionality to connect the gathered values and build a complete context tree out of this multiple node information."
---->Not sure if i understood it right --->
Each thread gets an unique ID and an continuous number for each method invocation done by this thread. This way each invocation can be associated with its thread.
...
- Active pushing of invocation sequence id from one thread to another
- hard to realize: how do we know that the next method instrumented will be invoked in a new thread
- at this point in time threadlocal information of the caller is no longer available
- It would be necessary to extend the method signature of all methods of all classes that inherit Thread / Runnable with an additional information (the invocation sequence) ... still very unclear
- Alternative would be to use JVM wide identification of the invocation sequence id with the respective thread
...
Brain dump:
Possible approach for continues Sending:
Analog to the container method, but the sending of information would be triggered for example after each 5 method closure.
To distinguish the method invocations done by the current thread from this done by other threads, each thread\runnable would get an ID(Remember thread pools and runnable reuse).