On Wed, Jul 31, 2013 at 3:15 PM, Kasun Gajasinghe <[email protected]> wrote:
> > 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. > > +1. Thanks for the clarification kasun & sagara. Thanks, Sinthuja. 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> > > > * > * > -- *Sinthuja Rajendran* Software Engineer <http://wso2.com/> WSO2, Inc.:http://wso2.com Blog: http://sinthu-rajan.blogspot.com/ Mobile: +94774273955
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
