Yes, this method is what caused a huge performance issue in servlet transport On Apr 7, 2011 2:52 PM, "Danushka Menikkumbura" <[email protected]> wrote: > Currently Qpid authorization plugin retrieves the user realm using > registryService.getConfigUserRegistry().getUserRealm() which spends around > 70% of the processing time. I am going to switch it to use the realm > service. It should solve this issue. > > Danushka > > On Thu, Apr 7, 2011 at 2:13 PM, Supun Kamburugamuva <[email protected]> wrote: > >> Is it possible to disable eventing for the moment and get this to a >> working state? Because we are blocked on everything because of this. >> >> Thanks, >> Supun.. >> >> On Thu, Apr 7, 2011 at 12:19 PM, Senaka Fernando <[email protected]> wrote: >> > Hi Danushka, >> > >> > On Thu, Apr 7, 2011 at 7:18 AM, Danushka Menikkumbura < [email protected] >> > >> > wrote: >> >> >> >> Also if this particular call is costly we can optimise some of them. But >> I >> >> think it is supposed to be used quite often. Isn't it? >> > >> > Yes. IMHO, the optimization could be done at the event-component level >> > right, to avoid an unwanted call to Qpid. The publishers would generate >> > events whenever some thing interesting happens and forward it to the >> broker. >> > These go through the event component which manages the brokering, and >> then >> > comes into Qpid for routing. So, if we could make the event component a >> bit >> > more intelligent to only forward messages to Qpid if needed (some form of >> > caching is needed), we should be able to avoid this right? >> > >> > WDYT? >> > >> > Thanks, >> > Senaka. >> >> >> >> Danushka >> >> >> >> On Thu, Apr 7, 2011 at 6:41 AM, Danushka Menikkumbura < >> [email protected]> >> >> wrote: >> >>>> >> >>>> Why 'registryService.getConfigUserRegistry().getUserRealm();' getting >> >>>> too long to respond? This is a widely used statement available on unit >> >>>> tests. Are those failing as well? If not, why is this happening during >> >>>> runtime only? >> >>> >> >>> Yes. Senaka I think this is the issue that we need to address as I can >> >>> see. >> >>> >> >>> Danushka >> >>> >> >> >> >> >> >> _______________________________________________ >> >> Carbon-dev mailing list >> >> [email protected] >> >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> >> > >> > >> > >> > -- >> > Senaka Fernando >> > Product Manager - WSO2 Governance Registry; >> > Associate Technical Lead; WSO2, Inc.; http://wso2.com >> > Member; Apache Software Foundation; http://apache.org >> > >> > E-mail: senaka AT wso2.com >> > P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818 >> > Linked-In: http://www.linkedin.com/in/senakafernando >> > >> > Lean . Enterprise . Middleware >> > >> > >> > _______________________________________________ >> > Carbon-dev mailing list >> > [email protected] >> > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > >> > >> >> >> >> -- >> Supun Kamburugamuva >> Technical Lead & Product Manager, WSO2 Inc.; http://wso2.com >> Member, Apache Software Foundation; http://www.apache.org >> WSO2 Inc.; http://wso2.org >> E-mail: [email protected]; Mobile: +94 77 431 3585 >> Blog: http://supunk.blogspot.com >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
