You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sadeep Jayasumana <ga...@gmail.com> on 2011/07/13 08:02:12 UTC
Framework for recording Axis2 latency statistics
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.
Re: Framework for recording Axis2 latency statistics
Posted by Afkham Azeez <af...@gmail.com>.
On Wed, Jul 13, 2011 at 6:29 PM, Deepal Jayasinghe <de...@gmail.com>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.
>
Tomcat has a RequestInfo object associated with each request, and calls a
statistics summarization method, after the response is created. This is tied
to the Tomcat request processor, and not part of the Connectors.
> 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.
>
>
+1
> Deepal
>
> On Wed, Jul 13, 2011 at 8:46 AM, Supun Kamburugamuva <su...@gmail.com>
> 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 <de...@gmail.com>
> 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 <
> gayansadeep@gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>> On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga
> >>> <sa...@gmail.com> 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
> >>>> <ga...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
> >>>> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sadeep
> >>
> >>
> >>
> >> --
> >> Afkham Azeez
> >> Director of Architecture; WSO2, Inc.; http://wso2.com,
> >> Member; Apache Software Foundation; http://www.apache.org/
> >>
> >> email: azeez@wso2.com 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: supun@wso2.com; Mobile: +94 77 431 3585
> > Blog: http://supunk.blogspot.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> > For additional commands, e-mail: java-dev-help@axis.apache.org
> >
> >
>
>
>
> --
> http://blogs.deepal.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com,
*Member; Apache Software Foundation;
**http://www.apache.org/*<http://www.apache.org/>
*
*
*email: **azeez@wso2.com* <az...@wso2.com>* 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*
*
*
Re: Framework for recording Axis2 latency statistics
Posted by Sadeep Jayasumana <ga...@gmail.com>.
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 <de...@gmail.com>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 <su...@gmail.com>
> 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 <de...@gmail.com>
> 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 <
> gayansadeep@gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>> On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga
> >>> <sa...@gmail.com> 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
> >>>> <ga...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
> >>>> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sadeep
> >>
> >>
> >>
> >> --
> >> Afkham Azeez
> >> Director of Architecture; WSO2, Inc.; http://wso2.com,
> >> Member; Apache Software Foundation; http://www.apache.org/
> >>
> >> email: azeez@wso2.com 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: supun@wso2.com; Mobile: +94 77 431 3585
> > Blog: http://supunk.blogspot.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> > For additional commands, e-mail: java-dev-help@axis.apache.org
> >
> >
>
>
>
> --
> http://blogs.deepal.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Sadeep
Re: Framework for recording Axis2 latency statistics
Posted by Deepal Jayasinghe <de...@gmail.com>.
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 <su...@gmail.com> 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 <de...@gmail.com> 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 <ga...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>> On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga
>>> <sa...@gmail.com> 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
>>>> <ga...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
>>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Sadeep
>>
>>
>>
>> --
>> Afkham Azeez
>> Director of Architecture; WSO2, Inc.; http://wso2.com,
>> Member; Apache Software Foundation; http://www.apache.org/
>>
>> email: azeez@wso2.com 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: supun@wso2.com; Mobile: +94 77 431 3585
> Blog: http://supunk.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
http://blogs.deepal.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Framework for recording Axis2 latency statistics
Posted by Supun Kamburugamuva <su...@gmail.com>.
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 <de...@gmail.com> 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 <ga...@gmail.com>
> wrote:
>>
>> Hi,
>> On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga
>> <sa...@gmail.com> 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
>>> <ga...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Sadeep
>
>
>
> --
> Afkham Azeez
> Director of Architecture; WSO2, Inc.; http://wso2.com,
> Member; Apache Software Foundation; http://www.apache.org/
>
> email: azeez@wso2.com 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: supun@wso2.com; Mobile: +94 77 431 3585
Blog: http://supunk.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Framework for recording Axis2 latency statistics
Posted by Deepal jayasinghe <de...@gmail.com>.
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
> <gayansadeep@gmail.com <ma...@gmail.com>> wrote:
>
> Hi,
>
> On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga
> <sagara.gunathunga@gmail.com <ma...@gmail.com>>
> 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
> <gayansadeep@gmail.com <ma...@gmail.com>> 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: java-dev-unsubscribe@axis.apache.org
> <ma...@axis.apache.org>
> For additional commands, e-mail: java-dev-help@axis.apache.org
> <ma...@axis.apache.org>
>
>
>
>
> --
> Sadeep
>
>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com,
> /Member; Apache Software Foundation; //http://www.apache.org//
> /
> /
> /email: //azeez@wso2.com/ <ma...@wso2.com>/ 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/
> /
> /
>
Re: Framework for recording Axis2 latency statistics
Posted by Afkham Azeez <af...@gmail.com>.
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 <ga...@gmail.com>wrote:
> Hi,
>
> On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga <
> sagara.gunathunga@gmail.com> 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
>> <ga...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Sadeep
>
--
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com,
*Member; Apache Software Foundation;
**http://www.apache.org/*<http://www.apache.org/>
*
*
*email: **azeez@wso2.com* <az...@wso2.com>* 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*
*
*
Re: Framework for recording Axis2 latency statistics
Posted by Sadeep Jayasumana <ga...@gmail.com>.
Hi,
On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga <
sagara.gunathunga@gmail.com> 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
> <ga...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Sadeep
Re: Framework for recording Axis2 latency statistics
Posted by Sagara Gunathunga <sa...@gmail.com>.
+1
Sadeep , I have few questions
1.) Is it possible to make your framework pluggable ? I mean users can
enable and disable this feature.
2.) Can you explain bit of a implementation level details of your
suggestion ? Whether you use Observer like pattern to collect those
statistics ?
Thanks !
On Wed, Jul 13, 2011 at 11:32 AM, Sadeep Jayasumana
<ga...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org