Approaches from thesis(Inter-JVM)

Owned by Former user (Deleted)
Last updated: Jul 12, 2012
2 min read

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 PicoContainer 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 could 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(sequence 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 ThreadLocal is set with RunnableReflection on the current runnable.