This page describes all problems, tasks and solution approaches regarding tracing of method invocations that can span over multiple JVMs.
...
Place the information even before the message gets to the sending unit.
(Probably the method signature has to be changed. Research)
Idea 2:
Sending the ID of the transaction context parallel to the communication of the monitored application.
For example use ssh tunneling to send a preparing message to the other agent. This way the receiving agent would know, that the next incoming message is in context of a particular transaction.
Maybe its possible to use the ssh tunneling to synchronize the messages and make sure, that no message goes between the "heads-up" and the actual message from the application.
(Analysis)
...
To put a additional communication layer under all application layers to realize the inter-JVM tracking.
Could be combined with idea1. (Wrapping interface)
Idea 4:
Wrap the message itself to add information.
Will not work, when the receiver is not instrumented.
Questions / Possible Problems
- How can i recognize method invocations that are initiated from outside? What to do with the received transaction ID?
- How can i identify the source of a method invocation?
- How can i achieve that an caller and be uniquely recognized?
- Which communication protocols should be supported?
Is there a way, to protocol / log the serialized data transfered with RMI so that it can be used to solve problems with Data Transfer Objects?
- How to instrument classes used by the agent itself (RMI)?
- Is it possible to keep track on a transaction with JVMs that are not instrumented?
Notes:
The Approach must allow the target application to work, even when the receiving end is not instrumented.
Braindumb:
General thoughts about tracking:
...