On Thu, Apr 7, 2011 at 6:19 PM, Senaka Fernando <[email protected]> wrote:
> > > On Thu, Apr 7, 2011 at 5:26 PM, Supun Kamburugamuva <[email protected]>wrote: > >> On Thu, Apr 7, 2011 at 5:25 PM, Amila Suriarachchi <[email protected]> >> wrote: >> > >> > >> > 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? >> > >> > The root cause of this problem is registry publishes some unnecessary >> > events. i.e. registry can keep an attribute of each resource that >> whether >> > some one has subscribes to that resource or not since users subscribe to >> the >> > registry events using registry UI. Then fire events only for resources >> where >> > there is a subscriber already. >> >> +1 >> > > I'm -0. IMHO, I don't like this suggestion. > > If the registry can do this, why would we ever need the event broker? > > Also, we were using eventing so far, and we did not have such bottlenecks. > The new eventing implementation does not properly address this, which is > what needs to be fixed. > > If we go about making changes to the registry eventing implementation to > keep track of subscribers, I see no point of having a separate event broker. > I mean to keep some property whether some one has subscribed or not. yes it is a separate thing to decide whether it is correct to publish event for each and every registry resource change. Any way we need to fix any event broker performance issues. Actually there is hardly any advantage using a separate broker with registry since both subscription and message sending parts handle by the registry itself. But some one can take the advantage of features like hierarchical subscriptions and ability to subscribe using JMS Api etc .. thanks, Amila. > > Thanks, > Senaka. > > >> Supun.. >> >> > >> > thanks, >> > Amila. >> >> >> >> 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 >> >> >> > >> > >> > _______________________________________________ >> > 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 >> > > > > -- > *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 > >
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
