Hi, Will study how Tomcat handles this.
No abstract method will be added to AbstractTransportListener/Sender. Only getLatencyRecorder(), a concrete method, will be introduced to those classes so that all transport listeners/senders can use that method to obtain the LatencyRecorder object from the configuration context Thanks, Sadeep On Wed, Jul 13, 2011 at 6:29 PM, Deepal Jayasinghe <[email protected]>wrote: > I partially agree with you for the out going path, but for the > incoming path there is no streaming it just creates the Axiom object > by pointing to input stream. > > Application server likes Tomcat handle this, I am not 100% sure how > they do that, but it is useful to understand their approaches as well. > If you really want to do with transport listeners then do it as a none > abstract method, so that we will not break any existing user code. > > Deepal > > On Wed, Jul 13, 2011 at 8:46 AM, Supun Kamburugamuva <[email protected]> > wrote: > > Actually doing this at the handler level is the easiest thing. But it > > is not sufficient for a real production system where these parameters > > are critical for figuring out the system performance. > > > > There are many things happen at the transports like streaming, > > buffering etc. With a handler level implementation all these latencies > > are lost. Also note that the initial SOAP building happens in the > > transport as well. So by the time the handler is hit most of the bytes > > are read in to the system. So calculating at the handler level doesn't > > give a accurate number. We have done this at the transport level for > > the synapse NHTTP transport and it served quite good for synapse so > > far. > > > > Thanks, > > Supun.. > > > > On Wed, Jul 13, 2011 at 5:26 PM, Deepal jayasinghe <[email protected]> > wrote: > >> 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]> > >> 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/ > >> > >> email: [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 > >> > >> > >> > > > > > > > > -- > > Supun Kamburugamuva > > Technical Lead & Product Manager, WSO2 Inc.; http://wso2.com > > Member, Apache Software Foundation; http://www.apache.org > > WSO2 Inc.; http://wso2.org > > E-mail: [email protected]; Mobile: +94 77 431 3585 > > Blog: http://supunk.blogspot.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > -- > http://blogs.deepal.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Sadeep
