Thanks Sinthuja. It seems we should also do a profile testing, and see whether there is a performance hit when the BAM stat valve is used. In aPaaS scenario, I believe there are two requests to BAM for each request AS receives. One is to publish to tenant space, and another to publish to super tenant space.
I don't think we have performance issue like in the case of axis2 handler since we always check the "enable.statistics" context parameter in the webapp before continuing. This means that we can get rid of bam.xml config for webapp stat publshing. I always find it annoying having to update a file, and do a restart. :-) Let's do a perf test, and if there is not major performance issue, we can ignore bam.xml config. I agree with Sagara. We should let the webapp developer decide specifically enable stats if they need it. That way, they will be mindful on which webapps need stats and which are not. Further, they can add a context parameter to web.xml to configure this which means they won't have to bother doing UI based enable/disable as well. Thanks, KasunG On Wed, Jul 31, 2013 at 2:29 PM, Sagara Gunathunga <[email protected]> wrote: > > > > On Wed, Jul 31, 2013 at 1:52 PM, Sinthuja Ragendran <[email protected]>wrote: > >> >> Hi Kasun/Geeth, >> >> IMHO if bam.xml is enabled and the step2 also enabled, then by default we >> can enable the stats publishing for all web a pps. >> >> I believe if a use is doing step-1 and step-2, then he's interested to >> monitor his/her applications. If he doesn't want the stats to be sent for a >> particular web application, then of course he can disable it. But by >> default we can enable the step-3. >> >> WDYT? >> > > I think default behavior should be opposite to that ( I mean current > approach is correct), If a user want to enable stat for a specific app he > has explicitly enable it. Generally one AS instance can be used by number > of people to host their apps, say one want to monitor stat on his app if we > don't have option-3 then stat will published for all other apps too without > any acknowledgement from original authors of other apps, this is not > something AS can decide. > > Thanks ! > >> >> Thanks, >> Sinthuja. >> >> On Wed, Jul 31, 2013 at 1:18 PM, Kasun Gajasinghe <[email protected]>wrote: >> >>> We need step 2 since there must be a way to enable/disable webapp stats >>> tenant-wide. And, that's where we configure the BAM stream definition, BAM >>> Receiver URL, and credentials. So, we can't remove this one. >>> >> >>> I do not know the rationale behind having to enable/disable stat >>> publishing globally via bam.xml. We have simply followed the mechanism used >>> by ServiceDataPublishing to have consistency. BAM team, can you provide the >>> reason for this? >>> >>> We need to have an option to configure stat publishing per axis2 >>> service. This feature will not go in to 5.2.0 but will be available in a >>> future release. >>> >> >>> Thanks, >>> KasunG >>> >>> >>> On Wed, Jul 31, 2013 at 1:08 PM, Asanka Vithanage <[email protected]>wrote: >>> >>>> HI All, >>>> >>>> I have try to configure AS to publish web statistcs to BAM.But it >>>> seems (on user perspective) there are so many configuration steps need to >>>> follow to achieve this task. >>>> >>>> Steps required: >>>> 1. Need to enable <WebappDataPublishing>disable</WebappDataPublishing> >>>> on {AS_HOME}/repository/conf/etc/ and open bam.xml. >>>> >>>> 2. Need to select "Enable webapp stats" check box on >>>> "Home>Configure>Webapp Data Publishing" through AS management console >>>> >>>> 3. Need to select " Enable BAM Statistics" check box on individual web >>>> application dashboard >>>> >>>> >>>> >>>> I feel we can get rid of first two steps and just enough the third >>>> step.So user can enable the web statistics publishing for a web app by >>>> following just one simple step. >>>> WDYT? >>>> >>>> Further that with current implementation we can't enable stat >>>> publishing for services one by one. >>>> We have to enable or disable stats publishing for all deployed >>>> services. Isn't that better to allow enable stat publishing at each service >>>> level? >>>> >>>> >>>> >>>> -- >>>> Asanka Vithanage >>>> Senior Software Engineer -QA >>>> Mobile: +94 0716286708 >>>> Email: [email protected] >>>> WSO2 Inc. www.wso2.com >>>> >>>> >>> >>> >>> -- >>> *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> >>> >>> >>> * >>> * >>> >> >> >> >> -- >> *Sinthuja Rajendran* >> Software Engineer <http://wso2.com/> >> WSO2, Inc.:http://wso2.com >> >> Blog: http://sinthu-rajan.blogspot.com/ >> Mobile: +94774273955 >> >> >> > > > -- > Sagara Gunathunga > > Senior Technical Lead; WSO2, Inc.; http://wso2.com > V.P Apache Web Services; http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > -- *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> * *
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
