Hi Ferry,
looks like, you're writing on several nodes.
You should concentrate all write access on one clusternode. I've
experienced best write performance using jcr single write multiple read
in clustered env. The more nodes with write access trying to aquire a
revision in journal, the more trouble you get.
I've read about a configuration option fine-grained-ism-locking, which
should optimize locking. I think we've tried it out, but it was buggy
for some time, making problems worse ;-). Maybe It's fixed now.
Have you had a look at
http://jackrabbit.apache.org/concurrency-control.html
for some hints on your deadlock issues?
Best regards
Michael
On 25.04.2013 14:08, Malzer Ferdinand OSP sIT wrote:
Hello,
We are using JackRabbit 2.4.3 with a clustering enabled. We are using postgres
9.1 for the cluster journal.
We have the following cluster nodes defined:
<Cluster id="batch">
<Journal class="org.apache.jackrabbit.core.journal.DatabaseJournal">
<param name="driver" value="com.edb.Driver"/>
<param name="url" value="jdbc:edb://pggcmsd.eb.lan.at:5435/gcmsd"/>
<param name="user" value="gdocappl"/>
<param name="password" value="{base64}YnVnczBidW5ueQ=="/>
<param name="schemaObjectPrefix" value="cluster_"/>
<param name="schema" value="postgresql"/>
</Journal>
</Cluster>
<Cluster id="gcmss2m1pvm1">
<Journal class="org.apache.jackrabbit.core.journal.DatabaseJournal">
<param name="driver" value="javax.naming.InitialContext"/>
<param name="url" value="jackrabbitpool"/>
<param name="schemaObjectPrefix" value="cluster_"/>
<param name="schema" value="postgresql"/>
</Journal>
</Cluster>
<Cluster id="gcmss2m2pvm1">
<Journal class="org.apache.jackrabbit.core.journal.DatabaseJournal">
<param name="driver" value="javax.naming.InitialContext"/>
<param name="url" value="jackrabbitpool"/>
<param name="schemaObjectPrefix" value="cluster_"/>
<param name="schema" value="postgresql"/>
</Journal>
</Cluster>
In the batch node's process we have created some thousands new nodes, while the
2 processes of cluster node gcmss2m1pvm1 and gcmss2m2pvm1 was still running.
When we try to create a new node in the process cluster node gcmss2m2pvm1 we
got a stuck thread which prevents all other further writing activities on this
node:
"[STUCK] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'"
daemon prio=1 tid=0x0a642708 nid=0x224 in Object.wait() [0x9fb76000..0x9fb78140]
at java.lang.Object.wait(Native Method)
- waiting on <0xac5ba2b8> (a
EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at java.lang.Object.wait(Object.java:474)
at
EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(WriterPreferenceReadWriteLock.java:240)
- locked <0xac5ba2b8> (a
EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
at
org.apache.jackrabbit.core.journal.AbstractJournal.internalLockAndSync(AbstractJournal.java:295)
at
org.apache.jackrabbit.core.journal.AbstractJournal.lockAndSync(AbstractJournal.java:284)
at
org.apache.jackrabbit.core.journal.DefaultRecordProducer.append(DefaultRecordProducer.java:51)
at
org.apache.jackrabbit.core.cluster.ClusterNode$WorkspaceUpdateChannel.updateCreated(ClusterNode.java:599)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:567)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1467)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1497)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:400)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:375)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:275)
at
org.apache.jackrabbit.core.ItemSaveOperation.perform(ItemSaveOperation.java:258)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:329)
at
org.apache.jackrabbit.core.session.SessionSaveOperation.perform(SessionSaveOperation.java:64)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:216)
at org.apache.jackrabbit.core.SessionImpl.perform(SessionImpl.java:361)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:812)
at
at.spardat.portal.cmsservices.repository.CabinetAccess.createCabinetNode(CabinetAccess.java:702)
at
at.spardat.portal.cmsservices.repository.CabinetAccess.createWebCabinet(CabinetAccess.java:159)
at
at.spardat.portal.cmsservices.repository.CabinetService.createWebCabinet(CabinetService.java:75)
at
at.spardat.gcmsclient.xma.cabinetadmin.server.CabinetDialog.onSaveCabinetInfo(CabinetDialog.java:182)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
at.spardat.xma.component.ComponentServer.executeRemoteCallImpl(ComponentServer.java:298)
at
at.spardat.xma.component.ComponentServer.executeRemoteCall(ComponentServer.java:274)
at
at.spardat.xma.rpc.RPCServletServer.dispatchRemoteCall(RPCServletServer.java:510)
at
at.spardat.xma.rpc.RPCServletServer.doPost0(RPCServletServer.java:210)
- locked <0xbe7724b8> (a at.spardat.xma.session.XMASessionServer)
at at.spardat.xma.rpc.RPCServletServer.doPost(RPCServletServer.java:84)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at
at.spardat.enterprise.beasecurity.AuthenticationFilter$1.run(AuthenticationFilter.java:150)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.security.Security.runAs(Security.java:41)
at
at.spardat.enterprise.beasecurity.AuthenticationFilter.doFilter(AuthenticationFilter.java:147)
at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at at.spardat.xma.session.HashFilter.doFilter(HashFilter.java:75)
at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(Unknown
Source)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at
weblogic.servlet.internal.WebAppServletContext.securedExecute(Unknown Source)
at weblogic.servlet.internal.WebAppServletContext.execute(Unknown
Source)
at weblogic.servlet.internal.ServletRequestImpl.run(Unknown Source)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
Does somebody knows what goes wrong and how to prevent this strange behaviour?
Thx in advance.
:-) ferry malzer
--
Mit freundlichen Grüßen
Michael Klenk
DIG
Digitale Medienberatungs- und Produktions- GmbH
Neckarstrasse 1/5
78727 Oberndorf
Amtsgericht Stuttgart HRB 480914
Geschäftsführer: Carsten Huber
Tel: +49 7423 8750 16
Fax: +49 7423 8750 23
E-Mail: [email protected]
Internet: http://www.DIG.de
Ein Unternehmen der Schwarzwälder Bote Mediengruppe.
