Instrumentation and tracing of Java classes and methods for each logged-in user in a Java web-based application

[vishal_m2]

Hi

I have a specific requirement of tracing each logged in user's user journey in a multi-user, multi-session Java web-based application environment. Does Byteman provide any existing solutions/API for profiling concurrent users such that each user journey can be traced during a single instance of profiling/instrumentation?

Thanks,

Vishal

[adinn]

Hi Vishal,

vishal_m2  wrote:

I have a specific requirement of tracing each logged in user's user journey in a multi-user, multi-session Java web-based application environment. Does Byteman provide any existing solutions/API for profiling concurrent users such that each user journey can be traced during a single instance of profiling/instrumentation?

Byteman does not provide anything that implements this as a complete ready-to-use package. However, it may be possible to achieve what you want using Byteman.

It would be worth looking at the dtest contrib package to see how it can be used to instrument and remotely monitor calls to specific methods of interest. dtest generates an audit trail logging  calls to those instrumented methods and offers a simple way of searching the audit for specific log records. You could try modifying dtest so that it adds information about the current thread to the audit, allowing you to associate calls belonging to each specific thread of control. If you can also attach some user-specific identifier to the  thread then that might allow you associate the audit traces with a user.

Hope that helps :-)

regards,

Andrew Dinn

[matapurkar]

Hi Andrew,

Thanks for the response! One assumption I forgot to include is that we do not have access to the source code of the deployed application and only have the war file.

Please confirm if we would be able to achieve this with only the war file available.

Thanks & Regards,

Vishal

[adinn]

Hi Vishal,

Yes, Byteman does not need source code in order to instrument classes. Nor does the dtest package. In order to instrument, say, entry and exit trace using dtest you would need to provide the names of classes you want to instrument or, if you want to be more specific, the names specific methods on those classes. The dtest program code usually needs to be able to load the required classes from the war file but you can also just give it a list of class and method names+signatures and it will upload rules based on that list.

Actually, you can also generate trace at intermediate points in the method body when you don't have the source code - for example at the point where one method calls another method. However, since you don;t have the source you will have to read the bytecode to work out where it is possible to inject code. Anyway, it doesn't sound like you really need this capability.

regards,

Andrew Dinn

[ochaloup]

I would like mention one restriction of the dtest remote monitoring which is the dtest monitoring tool needs to be available for contacting from the app program. In other words, the dtest helper class running in the app program as the part of the byteman agent opens rmi connection in direction to the monitoring tool.

[matapurkar]

Thanks Andrew and Ondra,

While I understand that Byteman along with dtest helps with tracing of classes and method invocations of multiple users - and also helps with user journey tracing, I was going through Stackoverflow and found a similar requirement as of mine - trace program execution at runtime and trace the classes and methods that were executed.

java - Byteman - trace all classes and methods in a given package - Stack Overflow

Also, the way I have understood the usage of Byteman/dtest is that I need to first feed all the classes and method names of the deployed war file to Byteman - this would not be done by Byteman/dtest and that Byteman will initiate its instrumentation based on the list of classes we provide to it as an input. This would be an overhead for me as there would be situations when I have over 500 classes (and not counting their multiple methods).

From the above link, I found that Understand stores the tracing of runtime executed classes and methods in its database and provides an API that allows the developer/user to access the execution reports database - this provides the list of classes and methods executed at runtime.

[adinn]

matapurkar  wrote:

While I understand that Byteman along with dtest helps with tracing of classes and method invocations of multiple users - and also helps with user journey tracing, I was going through Stackoverflow and found a similar requirement as of mine - trace program execution at runtime and trace the classes and methods that were executed.

java - Byteman - trace all classes and methods in a given package - Stack Overflow

Yes, it was me who originally replied to that post. I have had several such requests to allow some sort of way to track whatever class or method might get executed at runtime. Most of the time it is to allow a wildcard pattern for the class or method such as

CLASS *
METHOD *

or maybe just

CLASS org.my.*
METHOD *

The problem with providing something like this is that it kills performance.

1. Byteman makes bytecode changes online so adding wildcard patterns like this will slow down classloading enormously as Byteman checks for and then instruments every class as it gets loaded.
2. wildcard injection will also slow down execution as Byteman rules get triggered for a large proportion of method call.
3. the injected code will invalidate many of the optimizations implemented by the JIT compiler

n.b. the last point is probably the biggest killer; for almost all real apps JIT compilation is critical to making Java run fast and with a low memory footprint.

So, don't hold your breath because wildcards are not going to happen.

That is why I recommended an approach like dtest where you generate specific rules for only classes and methods you are interested in. Of course, if you run dtest over a stupidly large number of classes and methods you can still flood your code base with a vast number of rules and end up running into problems 2 and 3. However, by specifying an exact class and/or method for each rule the cost of 1 can be minimized even when there are many thousands of rules.

If you really want to trace everything that is executing at runtime then I suggest you look at some other tool. Personally, I'd advise you to give up on what you are trying, either restricting the scope of your interest to a small subset of classes or using a debugger to find out what is going on. Global tracing at runtime may be possible (even informative) for small programs but it is incredibly verbose when applied to any reasonable sized program so the output is next to useless. Also, injecting tracing code is a highly invasive change which invariably radically changes a program's behaviour. In consequence, it almost always invalidates whatever trace info you obtain because it is no longer a faithful record of what your app actually does at runtime (this is the ultimate rationale for why Byteman does not provide a wildcard injection capability).

matapurkar  wrote:

From the above link, I found that Understand stores the tracing of runtime executed classes and methods in its database and provides an API that allows the developer/user to access the execution reports database - this provides the list of classes and methods executed at runtime.

Understand? I have no idea what that does. However, if it works for you then go ahead and use it.

regards,

Andrew Dinn