On Mon, Jul 15, 2013 at 4:39 PM, Samisa Abeysinghe <[email protected]> wrote:
> So we are making the AS WebApp BAM toolkit tenant aware? > No. Current AS WebApp stat publishing component publishes data to tenant's keyspace (it is tenant aware). We need to make it possible to publish to ST's keyspace regardless of whether the tenant wants to publish stats or not (because the aPaaS vendor can only access his i.e. ST keyspace and we want all the stats with us). This is what we do in SLive (publishing to ST's keyspace). > > > On Mon, Jul 15, 2013 at 11:47 AM, Shariq Muhammed <[email protected]> wrote: > >> Hi Samisa, >> >> On Mon, Jul 15, 2013 at 8:12 AM, Samisa Abeysinghe <[email protected]>wrote: >> >>> Are we not re-using what we already have in AS? What are we inventing >>> here? >>> >> >> Yes the plan is to reuse what's been done in AS. However there are some >> changes we need to do to support this in aPaaS space, for example in AS >> tenant's are allowed to publish to an event stream / CF of their choice, >> but in the *live system all stats should be published to a common ST space >> so that we / provider can centrally manage / analyze the statistics etc. So >> we need to incorporate this to the existing component ... >> >> >>> >>> >>> 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. >>>> Usereither 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 >>> >> >> >> >> -- >> Thanks, >> Shariq. >> Phone: +94 777 202 225 >> > > > > -- > > 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 > > -- *Amila Maharachchi* Senior Technical Lead WSO2, Inc.; http://wso2.com Blog: http://maharachchi.blogspot.com Mobile: +94719371446
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
