On Thu, Apr 14, 2011 at 6:00 PM, Hiranya Jayathilaka <[email protected]>wrote:
> > > On Thu, Apr 14, 2011 at 5:55 PM, Amila Suriarachchi <[email protected]>wrote: > >> is this related to registry deadlock issue? >> >> Lets review this issue with registry team as the first thing after the >> vacation. >> > > Yes +1 > +1. Thanks, Senaka. > > Thanks, > Hiranya > > >> >> thanks, >> Amila. >> >> >> On Thu, Apr 14, 2011 at 4:13 PM, Hiranya Jayathilaka >> <[email protected]>wrote: >> >>> Folks, >>> >>> Have we found a way to fix this issue? As it stands now, ESB UI is >>> completely unusable due to this. It takes about 2 minutes to complete a >>> simple proxy service creation operation. Also it throws out exceptions >>> almost continuously: >>> >>> [2011-04-14 16:08:47,032] ERROR >>> {org.wso2.carbon.qpid.authorization.service.qpid.QpidAuthorizationPlugin} - >>> Error while retrieving UserRegistry : Failed to add the root collection to >>> the coreRegistry. >>> [2011-04-14 16:08:49,053] ERROR >>> {org.wso2.carbon.registry.core.jdbc.dao.JDBCResourceDAO} - Failed to get >>> the resource at path /_system/config. Timeout trying to lock table >>> "REG_RESOURCE"; SQL statement: >>> SELECT REG_MEDIA_TYPE, REG_CREATOR, REG_CREATED_TIME, REG_LAST_UPDATOR, >>> REG_LAST_UPDATED_TIME, REG_VERSION, REG_DESCRIPTION, REG_CONTENT_ID FROM >>> REG_RESOURCE WHERE REG_PATH_ID=? AND REG_NAME IS NULL AND REG_TENANT_ID=? >>> [50200-140] >>> org.h2.jdbc.JdbcSQLException: Timeout trying to lock table >>> "REG_RESOURCE"; SQL statement: >>> SELECT REG_MEDIA_TYPE, REG_CREATOR, REG_CREATED_TIME, REG_LAST_UPDATOR, >>> REG_LAST_UPDATED_TIME, REG_VERSION, REG_DESCRIPTION, REG_CONTENT_ID FROM >>> REG_RESOURCE WHERE REG_PATH_ID=? AND REG_NAME IS NULL AND REG_TENANT_ID=? >>> [50200-140] >>> at org.h2.message.DbException.getJdbcSQLException(DbException.java:327) >>> at org.h2.message.DbException.get(DbException.java:167) >>> at org.h2.message.DbException.get(DbException.java:144) >>> at org.h2.table.RegularTable.doLock(RegularTable.java:466) >>> at org.h2.table.RegularTable.lock(RegularTable.java:404) >>> at org.h2.table.TableFilter.lock(TableFilter.java:139) >>> at org.h2.command.dml.Select.queryWithoutCache(Select.java:554) >>> at org.h2.command.dml.Query.query(Query.java:241) >>> at org.h2.command.CommandContainer.query(CommandContainer.java:80) >>> at org.h2.command.Command.executeQuery(Command.java:132) >>> at >>> org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:96) >>> at >>> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) >>> at >>> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) >>> at >>> org.wso2.carbon.registry.core.jdbc.dao.JDBCResourceDAO.getResourceMetaData(JDBCResourceDAO.java:1112) >>> at >>> org.wso2.carbon.registry.core.jdbc.dao.JDBCResourceDAO.getResource(JDBCResourceDAO.java:1172) >>> at >>> org.wso2.carbon.registry.core.jdbc.dao.JDBCResourceDAO.get(JDBCResourceDAO.java:229) >>> at >>> org.wso2.carbon.registry.core.jdbc.dao.JDBCResourceDAO.get(JDBCResourceDAO.java:225) >>> at >>> org.wso2.carbon.registry.core.session.UserRegistry.addRootCollection(UserRegistry.java:353) >>> at >>> org.wso2.carbon.registry.core.session.UserRegistry.init(UserRegistry.java:262) >>> at >>> org.wso2.carbon.registry.core.session.UserRegistry.<init>(UserRegistry.java:199) >>> at >>> org.wso2.carbon.registry.core.jdbc.EmbeddedRegistryService.getUserRegistry(EmbeddedRegistryService.java:426) >>> at >>> org.wso2.carbon.registry.core.jdbc.EmbeddedRegistryService.getRegistry(EmbeddedRegistryService.java:446) >>> at >>> org.wso2.carbon.registry.core.jdbc.EmbeddedRegistryService.getConfigUserRegistry(EmbeddedRegistryService.java:493) >>> at >>> org.wso2.carbon.registry.core.jdbc.EmbeddedRegistryService.getConfigUserRegistry(EmbeddedRegistryService.java:507) >>> at >>> org.wso2.carbon.registry.core.jdbc.EmbeddedRegistryService.getConfigUserRegistry(EmbeddedRegistryService.java:503) >>> at >>> org.wso2.carbon.qpid.authorization.service.qpid.QpidAuthorizationPlugin.authorise(QpidAuthorizationPlugin.java:137) >>> at >>> org.apache.qpid.server.security.SecurityManager$11.allowed(SecurityManager.java:390) >>> at >>> org.apache.qpid.server.security.SecurityManager.checkAllPlugins(SecurityManager.java:245) >>> at >>> org.apache.qpid.server.security.SecurityManager.authorisePublish(SecurityManager.java:386) >>> at >>> org.apache.qpid.server.transport.ServerSessionDelegate.messageTransfer(ServerSessionDelegate.java:307) >>> at >>> org.apache.qpid.server.transport.ServerSessionDelegate.messageTransfer(ServerSessionDelegate.java:96) >>> at >>> org.apache.qpid.transport.MessageTransfer.dispatch(MessageTransfer.java:108) >>> at >>> org.apache.qpid.transport.SessionDelegate.command(SessionDelegate.java:50) >>> at >>> org.apache.qpid.server.transport.ServerSessionDelegate.command(ServerSessionDelegate.java:112) >>> at >>> org.apache.qpid.server.transport.ServerSessionDelegate.command(ServerSessionDelegate.java:96) >>> at org.apache.qpid.transport.Method.delegate(Method.java:159) >>> at org.apache.qpid.transport.Session.received(Session.java:500) >>> at org.apache.qpid.transport.Connection.dispatch(Connection.java:404) >>> at >>> org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:64) >>> at >>> org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:40) >>> at >>> org.apache.qpid.transport.MethodDelegate.messageTransfer(MethodDelegate.java:113) >>> at >>> org.apache.qpid.transport.MessageTransfer.dispatch(MessageTransfer.java:108) >>> at >>> org.apache.qpid.transport.ConnectionDelegate.command(ConnectionDelegate.java:54) >>> at >>> org.apache.qpid.transport.ConnectionDelegate.command(ConnectionDelegate.java:40) >>> at org.apache.qpid.transport.Method.delegate(Method.java:159) >>> at org.apache.qpid.transport.Connection.received(Connection.java:369) >>> at >>> org.apache.qpid.server.transport.ServerConnection.received(ServerConnection.java:195) >>> at >>> org.apache.qpid.server.transport.ServerConnection.received(ServerConnection.java:52) >>> at org.apache.qpid.transport.network.Assembler.emit(Assembler.java:95) >>> at >>> org.apache.qpid.transport.network.Assembler.assemble(Assembler.java:217) >>> at >>> org.apache.qpid.transport.network.Assembler.frame(Assembler.java:129) >>> at org.apache.qpid.transport.network.Frame.delegate(Frame.java:133) >>> at >>> org.apache.qpid.transport.network.Assembler.received(Assembler.java:100) >>> at >>> org.apache.qpid.transport.network.Assembler.received(Assembler.java:42) >>> at >>> org.apache.qpid.transport.network.InputHandler.next(InputHandler.java:187) >>> at >>> org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:103) >>> at >>> org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:42) >>> at >>> org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:102) >>> at >>> org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:36) >>> at >>> org.apache.qpid.transport.network.mina.MINANetworkDriver.messageReceived(MINANetworkDriver.java:337) >>> at >>> org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703) >>> at >>> org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362) >>> at >>> org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54) >>> at >>> org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800) >>> at >>> org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:243) >>> at >>> org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:305) >>> at >>> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061) >>> at >>> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575) >>> at java.lang.Thread.run(Thread.java:619) >>> >>> Thanks, >>> Hiranya >>> >>> >>> On Fri, Apr 8, 2011 at 4:36 PM, Amila Suriarachchi <[email protected]>wrote: >>> >>>> >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Hiranya Jayathilaka >>> Senior Software Engineer; >>> >>> WSO2 Inc.; http://wso2.org >>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>> Blog: http://techfeast-hiranya.blogspot.com >>> >> >> > > > -- > Hiranya Jayathilaka > Senior Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.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
