DX Application Performance Management

 View Only
  • 1.  Instrumenting Common Code in Application Server

    Posted Jul 15, 2015 11:29 AM

    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:




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




    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?





  • 2.  Re: Instrumenting Common Code in Application Server

    Broadcom Employee
    Posted Jul 15, 2015 01:12 PM

    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:



    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:



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


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




  • 3.  Re: Instrumenting Common Code in Application Server

    Posted Jul 15, 2015 01:21 PM



    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.



  • 4.  Re: Instrumenting Common Code in Application Server

    Posted Jul 15, 2015 01:27 PM

    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.




  • 5.  Re: Instrumenting Common Code in Application Server

    Posted Jul 15, 2015 01:43 PM


    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)



    App2 (ear2)



    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.


  • 6.  Re: Instrumenting Common Code in Application Server
    Best Answer

    Broadcom Employee
    Posted Jul 15, 2015 02:37 PM

    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.




  • 7.  Re: Instrumenting Common Code in Application Server

    Posted Jul 16, 2015 09:14 AM



    Thanks for confirming this.