Cross JVM instrumentation

Question

I'm spending sometime with DynaTrace. I'm impressed by its feature related to cross jvm instrumentation. In simple words, DynaTrace is able to instrument Java code creating trace with some statistical information. This is nothing new. There is a feature really interesting: when a call to an external JVM is execute, DynaTrace is able to link this new trace to the caller one (i.e. remote session bean, web services, remote RMI and so on). How could it be possible? I'm not able to immagine how to implement this feature? Any ideas?

Thank you

score 2 · Answer 1 · answered Feb 11 '15 at 14:03

2

Dynatrace actually doesnt rely on information from beans. As you correctly said in your questions - we are using Byte Code Instrumentation such as other tools in the market as well. We instrument key methods of certain frameworks, e.g: Servlet, Axis, JMS, JDBC, ... In the scenario where you make a call from one JVM to another using e.g: HTTP-based communication we instrument both the sending side of the HTTP Request as well as the receiving side on the other JVM. On the sending side we attach an additional HTTP Header with the ID of the current PurePath. PurePath is our patent technology. So - every PurePath (=every single transaction) gets a unique ID. This ID "travels" with the request, e.g: we put it on the HTTP Request as an HTTP HEader. ON the receiving side - your second JVM - we inspect that HTTP HEader and therefore know that all the data we collect belongs to that PurePath. This allows us to do real end-to-end tracing without relying on things like Beans or without correlating this data based on e.g: timestamps

Makes sense? If you have more questions let me know. I also recorded some videos and put on YouTube to explain the technology and the product itself: http://bit.ly/dttutorials

answered Feb 11 '15 at 14:03

Andreas Grabner

645
3
7

Hi Andreas, thank you for your answer. You use HTTP request as example, but I suppose inter-JVM mechanism works also for RMI, Web ServIces, and any other remote invocation technologies. I think you'll not alter mothid signature in case of RMI/EJB call, so how you transfer your ID to remote JVM? – DocJava Feb 12 '15 at 15:22
Correct. We are not altering any method signatures. We figured out other ways to pass that "PurePath ID" from the caller to the callee. Thats true for RMI, JMS, Thread Pooling, ... I can't share all technical details how we implement it for the different protocols - but - simply give it a try and you will see it works without doing any modifications. It doesnt break anything in case you only instrument one side either. All tested well and running in large scale systems of our users. Give it a try. I run the 30 day free trial program: http://bit.ly/dttrial – Andreas Grabner Feb 12 '15 at 15:25
Hi Andreas, thank you again for your answer. I can understand you cannot share technical implementation of a commercial product. But that is information I'm looking for even if as a generic description. – DocJava Feb 16 '15 at 10:01
Just as with HTTP we found ways to "add" our PurePath ID to the protocol without breaking any of the components involved in that communication. With HTTP we use an HTTP Header. For RMI the approach is a bit different. unfortunatley I cant tell you the exact details as much as I would love to. For JMS or MSMQ we use Message Properties. Same is true for WCF. – Andreas Grabner Feb 16 '15 at 10:30
@AndreasGrabner - I understand that PurePath is patented as it is, with all implementation details, but what about the idea of code instrumentation to match HTTP communication via additional HTTP header? Should it also be seen as patented? I would like to make such tool with similar approach and not sure where your patent "ends"... – Konrad Kokosa Aug 12 '15 at 14:14
I guess there is no patent on putting a custom HTTP Header on each request for tag&trace. You should be save to move forward with that approach – Andreas Grabner Aug 24 '15 at 14:30

score 0 · Answer 2 · answered Dec 23 '14 at 08:09

This information is normally extracted using MXBeans. Such beans provide a standard API for accessing standard runtime information. Similarly, such applications often scan the class loaders for specific classes and extract relevant information by hard-coded access. This is why less popular solutions are often not supported by monitoring tools.

Cross JVM instrumentation

2 Answers2