DX Application Performance Management

We have several applications running under a single Websphere application server (WAS). Each application has their own pbd file which are all loaded when the server starts. There is common code shared by some of the applications that requires instrumentation. For example:

application1.pbd

TraceOneMethodOfClass: com.sample.CommonClass execute BlamePointTracer "app1|{classname}|{method}"

application2.pbd

TraceOneMethodOfClass: com.sample.CommonClass execute BlamePointTracer "app2|{classname}|{method}"

In the pbd the investigator tree path is different based on the application (app1 vs app2).

What happens is that if app1 calls this class/method (CommonClass.execute()) the results in the investigator show up under both investigator tree paths (app1 and app2). I would like the results to only show up for the specific application. Is there any way via a directive or tracer or other than can segment common class and methods by their application?

Thanks,

Mike

Hi Mike,

If both pbds are loaded there are two tracers with different metric paths for that method. So any time that that method is executed both tracers will be executed and both metrics will be created.

Unless there is a parameter or field that identifies where the call is coming from you cannot differentiate between the two. If you got that differentiation you would need a custom name formatter and a custom pbd that goes something like:

common.pbd

TraceOneMethodOfClass: com.sample.CommonClass execute OriginBlamePointTracer "{caller}|{classname}|{method}"

So is there a way to differentiate? Do you want to invest in CA Services to get this?

Otherwise I would suggest:

common.pbd

TraceOneMethodOfClass: com.sample.CommonClass execute BlamePointTracer "common|{classname}|{method}"

and in addition instrument the method that calls CommonClass.execute() in each app.

Ciao,

Guenter

Guenter,

Thanks for the reply. This is what I thought too.

Just to be clear, these are separate applications that are not sharing a common class (i.e. a single common jar file). These are separate applications (under one server) with duplicate common code in each ear file, I would have thought the classloader would somehow assist Introscope to differentiate the two identical classes.

Mike

Hi Mike,

To better explain\help you, we need more enlightening from you wrt application code and its functionality.

If I am not wrong, there must be some parameter\namespace value which would be differentiating request among your code for app1 and app2.

With less knowledge about your code snippet, I would suggest you to try using the "TraceOneMethodWithParametersIfFlagged" directive for pbd definition and use respective term in your path.

To elaborate with e.g., if you have ever observed webservice invoking class, it is something like - "com.***.YYY.HttpClient" and method:execute for all webservices.
But still you are able to differentiate using something like below pbd definition :
TraceOneMethodWithParametersIfFlagged: <Tracer Group> <method> <Tracer> "WebServices|Client|{namespace}|{operationname}"

So my point is, you have to identify at your code level that how your application is differentiating between them and then accordingly you can set respective directives to instrument it.

Hope it helps.

Regards,

Vaibhav

Vaibhav,

Does this make it more clear? If ear 1 has a controller A (in a jar file) packed with a common jar file and ear 2 has a controller B packed with a common jar file.

App1 (ear1)

ControllerA

CommonClass

App2 (ear2)

ControllerB

CommonClass

If ControllerB calls the CommonClass in its ear2, the CommonClass metrics show up under both App1 and App2 investigator field paths.

I am wondering if ConditionallyTraceOneMethodWithLabelIfInherits might be the way to go. Although you would have to know each calling class of the CommonClass which would be a maintenance nightmare.

Mike

Hi Mike,

we can't (or don't) differentiate by ear. If the class is loaded independently in both class loaders then both instances get instrumented with both tracers but appear in the same 2 metric paths.

ConditionallyTraceOneMethodWithLabelIfInherits should work but with the maintenance drawback that you outlined.

Ciao,

Guenter

Guenter,

Thanks for confirming this.

Mike