Tracing used EBJs
Hi,
We have an external "tracer" that needs to track which EJBs are used in an J2EE application to satisfy each individual client request. This "tracer" is an external program, which means that it runs in a different machine than the application server machine. What we need to do is to instrument/modify the middleware and/or communications layer between EJBs so that it sends a packet to the "tracer" indicating the EJBs used in a request. We think that we have to modify the EJB container to do this (but not sure). For example, when a client enters to the Welcome page, the application runs EJB1, EJB2 and EJB3. For this request, the "tracer" needs to receive a packet indicating that these three EJBs where used.
Any suggestion/idea?
[757 byte] By [
Nacho26a] at [2007-10-3 9:45:13]
There are actually two ways to do this in GlassFish using the Callflow Mechanism. The Callflow layer tracks multiple events like RequestStart, RequestEnd, MethodStart and Method End. You will need to look at the MethodStart events to determine if the call is for an EJB. The Callflow layer will give you detailed information about the EJB.
The first mechanism has been used by our self management infrastructure whereby they implement a listener with the Callflow Agent. Once the callflow method is hit an event is thrown to the listener that they capture and process.
The Pro: the Listener can easily be registered with the agent and is exposed as an external interface.
The Con: The event is thrown when the call is being is executed, so essentially the processing time that your handler takes is added to the call processing time.
The relevant files are
http://fisheye5.cenqua.com/browse/glassfish/appserv-core/src/java/com/sun/enterprise/admin/selfmanagement/event/CallflowEventListener.java
The public interfaces are at
http://fisheye5.cenqua.com/browse/glassfish/appserv-commons/src/java/com/sun/enterprise/admin/monitor/callflow
The second mechanism that I have just added about 3-4 weeks back sends events asynchronously to a different handler. The biggest advantage is that your method call does not have pay for your handler processing code time. It takes advantage of the efficient asynchronous code that we have added to decouple our database writing from the call processing times.
The con: Since we have just added this code, I have not yet exposed this in the appserv-commons directory but we can easily work that out if this is something that satisfies your needs.
You will need to implement a Handler and register it with the handler chain
http://fisheye5.cenqua.com/browse/glassfish/admin/monitor/src/java/com/sun/enterprise/admin/monitor/callflow
and implement the handle method. The handle method gets a bulk of TransferObjects (since this is handled asynchronously - we bullk them up). You will need to see if a particular TO is a type of MethodStartTO and extract the relevant information from there.
Once you have implemented either of these, you can start callflow monitoring using asadmin start-callflow-monitoring server and stop using asadmin stop-callfow-monitoring server commands and you are good to go.
I would believe it should not take you more than couple of hours to code this up. What do I know ? ;-) I implemented some of this :-).
For details on the callflow layer and mechanism, you can look at the following doc
https://glassfish.dev.java.net/javaee5/monitoring/callflow/callflow.html . My email is at the bottom - feel free to email me if you have further questions.
Thanks
Harpreet
