Hi Samisa, AS Webapp publishing is already tenant aware. Each tenant can configure to which BAM instance and to which stream name it wants to publish. What I gather from Shariq's mail is that they need request/response bandwidth in addition to what we offer right now.
I think we should add a dummy parameter to the webapp stat stream definition for now even though we do not know how to capture this stat at the moment. Then, we do not have to change the stream definition again and again in newer releases as happened before. Regards, KasunG 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? > > > 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 > > -- *Kasun Gajasinghe* Software Engineer; Development Technologies Team, WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe * * *blog: **http://kasunbg.org* <http://kasunbg.org> * twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg> * *
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
