You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by shailesh mangal <sh...@getzephyr.com> on 2011/02/10 09:32:42 UTC
Concurrency issues in 2.2.1: DefaultISMLocking.releaseReadLock(DefaultISMLocking.java:140)
We are still running into concurrency issues. Increasing log level to debug, we
observed following exception:
2011-02-10 00:13:46,928 DEBUG [http-8080-exec-7]
DefaultISMLocking.releaseReadLock(140) | pirnt call stack
java.lang.Exception: call stack.
at
org.apache.jackrabbit.core.state.DefaultISMLocking.releaseReadLock(DefaultISMLocking.java:140)
at
org.apache.jackrabbit.core.state.DefaultISMLocking.access$000(DefaultISMLocking.java:31)
at
org.apache.jackrabbit.core.state.DefaultISMLocking$1.release(DefaultISMLocking.java:41)
at
org.apache.jackrabbit.core.version.InternalVersionManagerImpl.getItem(InternalVersionManagerImpl.java:339)
at
org.apache.jackrabbit.core.version.InternalXAVersionManager.getItem(InternalXAVersionManager.java:429)
at
org.apache.jackrabbit.core.version.InternalVersionManagerBase.getVersion(InternalVersionManagerBase.java:94)
at
org.apache.jackrabbit.core.version.InternalXAVersionManager.getVersion(InternalXAVersionManager.java:58)
at
org.apache.jackrabbit.core.version.VersionManagerImplBase.getBaseVersion(VersionManagerImplBase.java:388)
at
org.apache.jackrabbit.core.VersionManagerImpl.access$900(VersionManagerImpl.java:72)
at
org.apache.jackrabbit.core.VersionManagerImpl$5.perform(VersionManagerImpl.java:201)
at
org.apache.jackrabbit.core.VersionManagerImpl$5.perform(VersionManagerImpl.java:197)
at
org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:188)
at
org.apache.jackrabbit.core.VersionManagerImpl.perform(VersionManagerImpl.java:95)
at
org.apache.jackrabbit.core.VersionManagerImpl.getBaseVersion(VersionManagerImpl.java:197)
Also noticed, InternalVersionManagerBase still uses DefaultISMLocking even if we
have specified following in both workspace and versioning sections of
repository.xml
<ISMLockingclass="org.apache.jackrabbit.core.state.FineGrainedISMLocking">
</ISMLocking>
One solution that seems to work is to
1. Remove transactionality
2. Use FineGrainedISMLocking
Unfortunately, 1 is not an option we can use in production.
________________________________
From: Raj <db...@gmail.com>
To: users@jackrabbit.apache.org
Sent: Mon, January 24, 2011 6:43:03 AM
Subject: Re: AW: Concurrency issues after upgrading to 2.2 from 1.6
is it possible to reduce locks by any other configuration Or by deploying a
custom ISMLocking implementation ?
If 80-90% operations are read and rest are write, what will be a better
strategy?
regards,
Raj
On Mon, Jan 24, 2011 at 1:12 PM, shailesh mangal <
shailesh.mangal@getzephyr.com> wrote:
> Hi Claus,
>
> Thanks, I looked at the issue and even tried the suggested patch. It didnt
> resolve our issue. We are now trying FineGrainedISMLocking. (This didnt
> work for
> us in JR - 1.6). Have you tried or are aware of any issues that it might
> introduce? In theory it sounds like a better choice over DefaultISMLocking,
> Why
> is it not a default choice? Are there tradeoffs one over other?
>
> -Shailesh
>
>
>
> ________________________________
> From: KÖLL Claus <C....@TIROL.GV.AT>
> To: "users@jackrabbit.apache.org" <us...@jackrabbit.apache.org>
> Sent: Sun, January 23, 2011 10:54:24 PM
> Subject: AW: Concurrency issues after upgrading to 2.2 from 1.6
>
> Hi,
>
> Looke at JCR-2865. Mabe you have the same Problem ..
>
> greets
> claus
>
> -----Ursprüngliche Nachricht-----
> Von: shailesh mangal [mailto:shailesh.mangal@getzephyr.com]
> Gesendet: Samstag, 22. Jänner 2011 00:28
> An: users@jackrabbit.apache.org
> Betreff: Re: Concurrency issues after upgrading to 2.2 from 1.6
>
> Sending it again to the group since I sent it around the holiday time.
>
> Its hard to believe that we are the only ones running into concurrency
> issues
> and I dont think our usecase is any special. Any suggestion is highly
> appreciated.
>
> Use case:
> Multiple threads trying to copy a few nodes under the same Parent Node
> using
> workspace.copy().
> Each thread has its own transaction and own session.
> All threads end up hanging forever and any subsequent read or write
> operation
> end up waiting for a lock.
>
> I tried this with JR 2.2 and 2.2.1
>
> -Shailesh
>
>
>
> ________________________________
> From: shailesh mangal <sh...@getzephyr.com>
> To: users@jackrabbit.apache.org
> Sent: Wed, December 29, 2010 12:44:07 AM
> Subject: Concurrency issues after upgrading to 2.2 from 1.6
>
> Hi All,
>
> We recently upgraded to 2.2 from current 1.6.4 as we were facing some
> concurrency issues. But 2.2 seems to have same concurrency issues.
>
> Scenario:
> We have three threads trying to copy same set of versionable nodes (about
> 300)
> using workspace.copy() under same parent node. Each thread has its own
> session.
> All threads hang indefinitely, however JVM doesnt report deadlock, it looks
> like
>
>
> all three threads are waiting. Here is the thread dump for all three
> threads:
> This appears to be similar to
> https://issues.apache.org/jira/browse/JCR-2828
> which is marked as fixed. Any suggestions would be highly appreciable.
>
> "http-80-Processor25" daemon prio=6 tid=0x4ec97400 nid=0xe88 in
> Object.wait()
> [0x51ffd000] java.lang.Thread.State: WAITING (on object monitor) at
> java.lang.Object.wait(Native Method) at
> java.lang.Object.wait(Object.java:485)
>
> at
>
>org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:124)
>)
>
>
> - locked <0x1bc95bc8> (a
> org.apache.jackrabbit.core.state.DefaultISMLocking)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.acquireWriteLock(InternalVersionManagerBase.java:182)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.startWriteOperation(InternalVersionManagerBase.java:286)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.internalCreateVersionHistory(InternalVersionManagerBase.java:411)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerImpl$1.run(InternalVersionManagerImpl.java:254)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerImpl$DynamicESCFactory.doSourced(InternalVersionManagerImpl.java:709)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerImpl.createVersionHistory(InternalVersionManagerImpl.java:251)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalXAVersionManager.createVersionHistory(InternalXAVersionManager.java:176)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.getVersionHistory(InternalVersionManagerBase.java:326)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalXAVersionManager.getVersionHistory(InternalXAVersionManager.java:58)
>)
>
>
> at
>
>org.apache.jackrabbit.core.BatchedItemOperations.copyNodeState(BatchedItemOperations.java:1758)
>)
>
>
> at
>
>org.apache.jackrabbit.core.BatchedItemOperations.copy(BatchedItemOperations.java:422)
>)
>
>
> at
>
> org.apache.jackrabbit.core.WorkspaceImpl.internalCopy(WorkspaceImpl.java:420)
> at org.apache.jackrabbit.core.WorkspaceImpl.copy(WorkspaceImpl.java:646)
>
> "http-80-Processor21" daemon prio=6 tid=0x4ec95c00 nid=0x1b18 in
> Object.wait()
> [0x51dbd000] java.lang.Thread.State: WAITING (on object monitor) at
> java.lang.Object.wait(Native Method) at
> java.lang.Object.wait(Object.java:485)
>
> at
>
>org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:124)
>)
>
>
> - locked <0x1bc95bc8> (a
> org.apache.jackrabbit.core.state.DefaultISMLocking)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.acquireWriteLock(InternalVersionManagerBase.java:182)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.startWriteOperation(InternalVersionManagerBase.java:286)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.checkin(InternalVersionManagerBase.java:571)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerImpl$4.run(InternalVersionManagerImpl.java:410)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerImpl$DynamicESCFactory.doSourced(InternalVersionManagerImpl.java:709)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerImpl.checkin(InternalVersionManagerImpl.java:406)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalXAVersionManager.checkin(InternalXAVersionManager.java:238)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.VersionManagerImplBase.checkoutCheckin(VersionManagerImplBase.java:190)
>)
>
>
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl.access$100(VersionManagerImpl.java:72)
>)
>
>
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl$1.perform(VersionManagerImpl.java:121)
>)
>
>
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl$1.perform(VersionManagerImpl.java:114)
>)
>
>
> at
>
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl.perform(VersionManagerImpl.java:95)
>)
>
>
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl.checkin(VersionManagerImpl.java:114)
>)
>
>
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl.checkin(VersionManagerImpl.java:100)
>)
>
>
> at org.apache.jackrabbit.core.NodeImpl.checkin(NodeImpl.java:2844)
> at
>
>com.thed.repository.RepositoryNodeHelper.setTestCaseProperties(RepositoryNodeHelper.java:250)
>)
>
>
>
>
> "http-80-Processor24" daemon prio=6 tid=0x4ec97000 nid=0x1b2c in
> Object.wait()
> [0x51f6d000] java.lang.Thread.State: WAITING (on object monitor) at
> java.lang.Object.wait(Native Method) at
> java.lang.Object.wait(Object.java:485)
>
> at
>
>org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:92)
>)
>
>
> - locked <0x1bc95bc8> (a
> org.apache.jackrabbit.core.state.DefaultISMLocking)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.acquireReadLock(InternalVersionManagerBase.java:196)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerImpl.getItem(InternalVersionManagerImpl.java:324)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.createInternalVersionItem(InternalVersionManagerBase.java:797)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerImpl.getItem(InternalVersionManagerImpl.java:329)
>)
>
>
> - locked <0x1bc95c38> (a
> org.apache.commons.collections.map.ReferenceMap)
> at
>
>
>org.apache.jackrabbit.core.version.InternalXAVersionManager.getItem(InternalXAVersionManager.java:429)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalVersionManagerBase.getVersion(InternalVersionManagerBase.java:94)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.InternalXAVersionManager.getVersion(InternalXAVersionManager.java:58)
>)
>
>
> at
>
>org.apache.jackrabbit.core.version.VersionManagerImplBase.getBaseVersion(VersionManagerImplBase.java:388)
>)
>
>
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl.access$900(VersionManagerImpl.java:72)
>)
>
>
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl$5.perform(VersionManagerImpl.java:201)
>)
>
>
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl$5.perform(VersionManagerImpl.java:197)
>)
>
>
> at
>
> org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200)
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl.perform(VersionManagerImpl.java:95)
>)
>
>
> at
>
>org.apache.jackrabbit.core.VersionManagerImpl.getBaseVersion(VersionManagerImpl.java:197)
>)
>
>
> at
> org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:2948)
> at
>
>
>com.thed.repository.TestcaseContentsManager.copyTestCases(TestcaseContentsManager.java:356)
>)
>
>
>
> Shailesh
>