How to trace methods:
...
- Slow (suboptimal implementation of getStackTrace())
- High memory consumption ( method calls can go very deep)
- There is a possibility that a JVM implementation does not provide this stack, since its not part of the JVM Specification.
Own Stack Trace approach
-großer Speicherverbrauch
...
Disadvantages:
- High memory consumption
- Slow (each method has to do a pop and push)
Method Signature approach
Zusätzlicher Methodenparameter. - Viel aufwand um die nativen Methodensignaturen zu ändern.
Container approach
Einfach die bereits gesammelten daten mit schicken mit den RMI.
-Großer Speicher und Netzwerkverbrauch, da die mitgeschickten Daten sehr groß werden könnenAn additional parameter is passed to each method.
Disadvantages:
- High effort to change the native method signatures
Container approach
See current solution.
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...
...
The invocation data is send to the server in small pieces, on every method entry and exit. This way there is no need to store the data until the method finishes, what reduce the stress on the target application. The network has to handle smaller packs, which is also good for the performance. Also the server has the possibility to process the data earlier and it can be displayed while the method is still executing.
- Die Aufrufinformationen werden beim Methodenstrart und end versendet.
- Ein Stack wird erschafft für jeden Thread, und die asynchronen Aufrufe werden damit verbunden.
Current solution:
Currently the sequence sensor is implemented as container, which collects all sensor(e.g. timer sensor) data starting from an defined start point (execution of a predefined method). This collected data is chronologically ordered, to allow to trace the invocation sequence.
But this is not suitable for asynchronous methods. TODO: Validate if this is the current state of the sequence sensor. Possibly there were improvements in the meantime.
...