Why not introduce two handlers which will do this, and make those handlers sit right at the top of the in-flow, and right at the back of the outflow. That way, nothing has to be changed, and transports listeners/senders don't have to be changed, and you don't have to depend on the transport listener/sender authors to do the correct thing? Of course, there may be a very small microsecond range error since the execution times in the listeners/senders will not be included.
On Wed, Jul 13, 2011 at 2:18 PM, Sadeep Jayasumana <[email protected]>wrote: > Hi, > > On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga < > [email protected]> wrote: > >> +1 >> >> Sadeep , I have few questions >> >> 1.) Is it possible to make your framework pluggable ? I mean users can >> enable and disable this feature. > > > Yes, user can enable/disable this feature using axis2.xml > > >> >> 2.) Can you explain bit of a implementation level details of your >> suggestion ? Whether you use Observer like pattern to collect those >> statistics ? >> >> > Here is a summery of the implementation > > 1. When axis2 server is starting up a LatencyRecorder (a newly introduced > class) instance is created and bound to the configuration context. > DeploymentLifeCycleListener is used for this purpose. LatencyRecorder > contains methods for transport listeners/senders to report message > arrival/departure. > > 2. A new method, getLatencyRecorder(), is introduced to > AbstractTransportListener and AbstractTransportSender classes, this method > basically returns the LatencyRecorder object bound to the configuration > context > > 3. When a message is received, the corresponding transport listener reports > it to the above LatencyRecorder object with the message context and message > arrival time > > 4. Message context properties are used to keep latency data related to that > message while it is inside Axis2 engine > > 5. When a message is sent back to the client, the corresponding transport > sender reports it to the LatencyRecorder object with the message context and > message departure time > > 6. A single threaded executor runs to average latency data reported and to > post them to the MBean > > In addition to this basic flow, it is also possible to report times when > Axis2 server calls an external web service before sending response to it's > client (as done in Apache Syanpse). > > Thanks, > Sadeep > > >> Thanks ! >> >> On Wed, Jul 13, 2011 at 11:32 AM, Sadeep Jayasumana >> <[email protected]> wrote: >> > Hi Devs, >> > I'm planning to implement a framework for monitoring latency statistics >> of >> > Axis2 server. The key purpose of this framework is to monitor average >> time >> > messages spend inside Axis2 server. Here is the summery of my approach. >> > 1. Time t1 is recorded by the transport listener when a request message >> is >> > received >> > 2. Time t2 is recorded by the transport sender when the response message >> is >> > sent back to the client >> > 3. Latency is recorded as (t2 - t1) >> > 4. Average latencies are made available via JMX. Statistics will be >> > available on short term basis(last 1 minute, last 5 minutes, etc.) and >> long >> > term basis(last 1 hour, last 5 hours, etc). >> > To implement this, all the transport listeners and senders should report >> > message arrival and departure to a central component that calculates >> > statistics and publishes them via JMX MBeans. Short term and long term >> > statistics will be available for in-transport name and out-transport >> name >> > combinations. (statistics for http-in & http-out, statistics for jms-in >> & >> > jms-out, etc.) >> > Further, this framework will be extensible and able to record meaningful >> > latencies when Axis2 is used in other projects such as Apache Synapse. >> > Any thoughts are welcome. >> > Thanks, >> > -- >> > Sadeep Jayasumana >> > Software Engineer >> > WSO2 Inc. >> > >> >> >> >> -- >> Sagara Gunathunga >> >> Blog - http://ssagara.blogspot.com >> Web - http://people.apache.org/~sagara/ >> LinkedIn - http://www.linkedin.com/in/ssagara >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Sadeep > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com, *Member; Apache Software Foundation; **http://www.apache.org/*<http://www.apache.org/> * * *email: **[email protected]* <[email protected]>* cell: +94 77 3320919 blog: **http://blog.afkham.org* <http://blog.afkham.org>* twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware* * *
