Remote Procedure Calls
Additional information has to be transmitted along with RPC- Messages, to allow to track remote method invocations. This additional information has to be cached by the agent on the other side and handled properly.
Therefor we need unique ID's for VMs/Threads/Methods.
Communication protocols that should be considered:
- Web-Services
- Cobra
- RMI (Different Implementations /Provider)
It could be considered, if one of the following ideas shouldn't be used on the other communication protocols. For example Cobra uses ORB and IIOP. Interceptors could be generated using the Proxy Factory Pattern. The same is possible for EJB with ProxyBeans. Unfortunately this approach can't be used, without facing performance issues.
Nevertheless it should be search for a way to trace with other RMI Implementations /Providers and Protocols (Webservice,Cobra,EJB).
RMI Instrumentation
The RMI-Stubs has to be instrument and extended in such a way, that IDs can be transmitted. To do that, the iTrace interface is injected.
Additional function call approach
One possible approach is, that right before each RPC an additional function would be invoked, that would set and transfer the ID.
This produces much overhead, since every RPC is in fact doubled. Additionally, the hash algorithm generating the ID is also resource consuming.
Marshall-unmarshall approach
An other approach is to instrument the marshall() and unmarshall() methods of the RMI-stubs. The method ID can be injected in the transmitted RMI-Message and then get by the other agent.
Instrumentation of classes used by the agent
Its not possible for a agent to instrument classes, that are used by itself. In this case the RMI classes.
To find a way, to modify this classes, the moment has to be identified and moved, when the Pico container is initializing the classes. To be able to work on the RMI classes the execution of the Ignore Pattern, that the agent uses to filter classes that shouldn't be instrumented, is moved before the Pico container starts initialization.
To instrument the RMI classes an additional agent (Tracing agent) is implemented, that runs and modifies the classes, before the actual InspectIT agent starts.
Implementation Tracing Agent
The Tracing Agent also runs an ignore check.
All already collected invocation data will be added and send with the RMI. This could lead to high memory and network consumption, because the collected data can get really big.
For RMI Tracking the marshall() and unmarshall() methods are modified, so that the current Invocation Identifier is also transmitted (Stream Injection).
The Hook Dispatcher is changed, so that the InvocationIdentifier is created.
The invocation hook uses the iCoreService interface and simulates an storage service to get the data from other sensors. Like in the container approach(sequense sensor).
For thread pools:
The fact is used, that Runnables stay unique and cannot be reused. Each Runnable gets an ID.
An Runnable cannot switch the Thread that is executed with.
The run() method is instrumented and the ThreadLokal is set with RunnableReflection on the current runnable.
Implementation of RunnableStack for the Runnable Tracing. Move to Runnables
The constructors of Runnable are instrumented so that each Runnable gets an ID.
The RunnableMap, generates the ID and provides the mapping to its Runnable (registerRunnable()).
The RunnableLocal uses the ID as key and stores the RunnableReflection..
The RunnableReflection uses a ThreadLocal to identify the currently run Runnable. This happens in the run() method.
(note)
R1 R2 R3- Whrn R3 is created in constructor of R2. And R1 calls R2. Then is R1 the parent of R3 not R2.
All with an currentRunnable variable that is handled properly.
In the same way are the current InvocationIdentifier inherited. (This reduces overhead)