I agree with Azeez, this has to be done with handler. I do not like the idea of keep changing the abstract transport listener (in fact I am -1 on that).
This is a nice feature but you need to make sure that you do not break anything. So, implement this feature using handlers, we have done similar stuffs with handlers. And add your handler phasefirst of transport phase (in), and phaselast of transport out. Thanks, Deepal > 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] <mailto:[email protected]>> wrote: > > Hi, > > On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga > <[email protected] <mailto:[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] <mailto:[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/ > <http://people.apache.org/%7Esagara/> > LinkedIn - http://www.linkedin.com/in/ssagara > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > > > > -- > Sadeep > > > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com, > /Member; Apache Software Foundation; //http://www.apache.org// > / > / > /email: //[email protected]/ <mailto:[email protected]>/ cell: +94 77 3320919 > blog: //http://blog.afkham.org// > twitter: //http://twitter.com/afkham_azeez// > linked-in: //http://lk.linkedin.com/in/afkhamazeez/ > / > / > /Lean . Enterprise . Middleware/ > / > / >
