Jboss portal and lock timeout
by devone
Hi everyone,
I have a JEMS installation of Jboss portal, in a cluster with 2 members, in
the last period some nodes of the cluster logs an error due to a lock
timeout.
Is this a configuration problem? Is a known bug?
I think that some portlet spends a lot of time to elaborate data or to load
a content from jackrabbit, until a timeout occurs.
Jboss AS 4.0.5
Jbos portal 2.4
This is the error:
15:20:50,262 ERROR [ContentGetCommand] Cannot get content
java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure
acquiring lock: fqn=/wsp_node/0b6f4296-7cc2-4461-bdf8-a72a42a4475c,
caller=GlobalTransaction:<null>:883, lock=write
owner=GlobalTransaction:<null>:879 (activeReaders=0,
activeWriter=Thread[http-192.168.120.12-8080-9,5,jboss], waitingReaders=0,
waitingWriters=0, waitingUpgrader=0)
at
org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.exists(JBo
ssCachePersistenceManager.java:435)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemSta
te(SharedItemStateManager.java:811)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedI
temStateManager.java:244)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalIte
mStateManager.java:171)
at
org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemState
Manager.java:261)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(Sessio
nItemStateManager.java:126)
at
org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:4
62)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:320)
at org.apache.jackrabbit.core.PropertyImpl.getNode(PropertyImpl.java:655)
at
org.apache.jackrabbit.core.NodeImpl.getVersionHistory(NodeImpl.java:3091)
at
org.jboss.portal.cms.impl.jcr.command.ContentGetCommand.execute(ContentGetCo
mmand.java:107)
at
org.jboss.portal.cms.impl.jcr.JCRCommandContext.execute(JCRCommandContext.ja
va:63)
at
org.jboss.portal.cms.impl.jcr.command.FileGetCommand.execute(FileGetCommand.
java:112)
at org.jboss.portal.cms.impl.jcr.JCRCommand.dispatch(JCRCommand.java:62)
at org.jboss.portal.cms.impl.jcr.JCRCMS.execute(JCRCMS.java:457)
at org.jboss.portal.cms.impl.jcr.ha.HAJCRCMS.execute(HAJCRCMS.java:169)
at sun.reflect.GeneratedMethodAccessor829.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java
:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at
org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java
:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at
org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOpe
rationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:26
4)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at
org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
at $Proxy1009.execute(Unknown Source)
at
com.ecommy.portlets.CMSView.CMSAbstractViewPortlet.doView(CMSAbstractViewPor
tlet.java:167)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:133)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:306)
at
org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletCont
ainer.java:518)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock:
fqn=/wsp_node/0b6f4296-7cc2-4461-bdf8-a72a42a4475c,
caller=GlobalTransaction:<null>:883, lock=write
owner=GlobalTransaction:<null>:879 (activeReaders=0,
activeWriter=Thread[http-192.168.120.12-8080-9,5,jboss], waitingReaders=0,
waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:500)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(Pess
imisticLockInterceptor.java:379)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLock
Interceptor.java:307)
at
org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLo
ckInterceptor.java:181)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterc
eptor.java:212)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java
:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreIntercep
tor.java:135)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.j
ava:365)
at
org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at
org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtIntercepto
r.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
at org.jboss.cache.TreeCache.get(TreeCache.java:3627)
at org.jboss.cache.TreeCache.get(TreeCache.java:3608)
at org.jboss.cache.TreeCache.get(TreeCache.java:3595)
at sun.reflect.GeneratedMethodAccessor798.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java
:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:26
4)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy138.get(Unknown Source)
at
org.jboss.portal.cms.hibernate.state.JBossCachePersistenceManager.exists(JBo
ssCachePersistenceManager.java:403)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemSta
te(SharedItemStateManager.java:811)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedI
temStateManager.java:244)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalIte
mStateManager.java:171)
at
org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemState
Manager.java:261)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(Sessio
nItemStateManager.java:126)
at
org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:4
62)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:320)
Caused by: org.jboss.cache.lock.TimeoutException: read lock for
/wsp_node/0b6f4296-7cc2-4461-bdf8-a72a42a4475c could not be acquired by
GlobalTransaction:<null>:883 after 15000 ms. Locks: Read lock owners: []
Write lock owner: GlobalTransaction:<null>:879
, lock info: write owner=GlobalTransaction:<null>:879 (activeReaders=0,
activeWriter=Thread[http-192.168.120.12-8080-9,5,jboss], waitingReaders=0,
waitingWriters=0, waitingUpgrader=0)
16 years, 3 months
Re: [jboss-user] [EJB 3.0] - Stability of the ejb3.1 spec in AS6M2?
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion
"Stability of the ejb3.1 spec in AS6M2?"
To view the discussion, visit: http://community.jboss.org/message/533140#533140
--------------------------------------------------------------
> Yucca Nel wrote:
>
> Yes :)
>
>
Okay. Now that we are on the same page (literally ;) ) here's some details about that error message. If you look at the same 19 section of the spec, you will *also* notice:
>
> Enterprise bean’s local business interface. If the bean class has a local business interface and neither implements the business interface nor specifies it as a local business interface using metadata annotations on the bean class, the Bean Provider must specify the fully-qualified name of the enterprise bean’s local business interface in the business-local element.
>
The usage of local/business-local and remote/business-remote is the most confused ones in EJB3.
Starting EJB3, we now have "business interface"(s), which is a Plain Old Java Interface. So you have *business* local and *business* remote interfaces (their annotations are @Local and @Remote respectively). To configure them in xml, you use <business-local> and/or <business-remote> elements. These are plain java interfaces (and are known as business interfaces) and provide a EJB3.x view for the bean. Furthermore, EJB3 is backward compatible. What this means is, you can have EJB2.x view for your bean. The EJB2.x view has a local/remote *(component)* interface and corresponding local/remote home interfaces. Such *component* local/remote interfaces extend javax.ejb.EJBLocalObject/javax.ejb.EJBObject respectively. The local/remote *component* interfaces are configured using the <local> (and/or) <remote> element in the xml. So if you use the <local> element in the xml, then you are using the EJB2.x view and are expected to provide a corresponding <local-home> element in the xml (or use a @LocalHome to annotate the local home interface)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/533140#533140]
Start a new discussion in EJB 3.0 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 3 months
[JBoss Portal] - Stability of the ejb3.1 spec in AS6M2?
by Yucca Nel
Yucca Nel [http://community.jboss.org/people/Yuccanel] created the discussion
"Stability of the ejb3.1 spec in AS6M2?"
To view the discussion, visit: http://community.jboss.org/message/533135#533135
--------------------------------------------------------------
Given that this is milestone 2 I was a bit surprised that basic deployment of small ear failed due to the following:
Caused by: org.jboss.metadata.validation.chain.ValidatorChainException: Validation has failed due to the following ValidationException(s) raised:
* EJB ManageUser has defined EJB2.x local component interface of org.jarbar.usermanager.model.LocalUserManager but has no localHome; ; Incomplete EJB2.x View [JBMETA-130]
at org.jboss.metadata.validation.chain.ejb.jboss.JBossMetaDataValidatorChain.validate(JBossMetaDataValidatorChain.java:130)
at org.jboss.ejb3.deployers.Ejb3MetadataProcessingDeployer.deploy(Ejb3MetadataProcessingDeployer.java:147)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
I read the ejb3.1 spec just to make sure that nothing has changed for the rules in DD for defiing Stateles session beans and chapter 19 of the spec states that it should be good enough to define a Local interface through the <local> element. More importnatly, ia there a current workaround for this?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/533135#533135]
Start a new discussion in JBoss Portal at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 3 months