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
_______________________________________________
Carbon-dev mailing list
[email protected]
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
