Are we not re-using what we already have in AS? What are we inventing here?
On Fri, Jul 12, 2013 at 12:27 PM, Geeth Munasinghe <[email protected]> wrote: > > On Fri, Jul 12, 2013 at 11:26 AM, Shariq Muhammed <[email protected]> wrote: > >> Hi folks, >> >> I was looking into capturing webapp statistics for aPaaS work, and came >> across the webapp.stat.publisher component written by the AS team. It >> uses a tomcat valve [1] and publish a whole heap of stats, the list can be >> found in the class at [2]. >> >> The new stat component captures way more data than the usage components >> we had before, only missing piece as of now is the request/response >> bandwidth. What we've done now is to patch tomcat RequestInfo.java class, >> if we can somehow capture the bandwidth also in the valve we can get rid of >> tomcat.patch, tomcat.fragment.dummy bundles and a few classes from tomcat >> .ext bundle in the kernel. >> >> By looking into the tomcat code, it seems we can get the coyote.Request >> (object in RequestInfo) within the valve, but the bandwidth values >> returned are 0. >> >> request.getCoyoteRequest().getBytesRead(); // => 0 >> request.getCoyoteRequest().getResponse().getContentWritten() // => 0 >> >> But the correct values are returned in the patched RequestInfo class, so >> I am still trying to figure out what could be the issue. If we can capture >> this value also at the value we can publish all properties from one place. >> >> So first of all I would like to know if it's fine to go ahead with this >> implementation and improve it to cater aPaaS requirements or do we need >> a separate bundle (would be a fork of this one in the end). IMO we should >> use this component and improve it since there is no point having 2 bundles >> doing the same thing. >> >> One concern, the component is designed for per tenant publishing, and the >> tenant chooses whether or not to publish and where to publish. If we are to >> capture stats centrally we need to publish to a ST CF regardless of >> tenant enable or disable statistics, can be done using a config option. >> >> @Geeth - Noticed that even after a tenant enable stat publishing for >> webapps, we need to again enable publishing per webapp. IMO the model >> should be that if a tenant enable publishing, stats for all deployed >> webapps should be published and tenant should be given the option to >> disable stats selectively. >> > > Currently we are giving two options for user to enable publishing. User > either can put context param in web.xml to enable statistic or enable from > ui. What we thought was user should be able to enable stats publishing per > webapp rather than publishing for all webapps deployed. > >> >> Thoughts ... ?! >> >> [1] - >> https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/data-agents/org.wso2.carbon.bam.webapp.stat.publisher/src/main/java/org/wso2/carbon/bam/webapp/stat/publisher/WebAppStatisticPublisherValve.java >> [2] - >> https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/data-agents/org.wso2.carbon.bam.webapp.stat.publisher/src/main/java/org/wso2/carbon/bam/webapp/stat/publisher/data/WebappStatEventData.java >> >> -- >> Thanks, >> Shariq. >> Phone: +94 777 202 225 >> > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
