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 <[email protected]> To: [email protected] 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 < [email protected]> 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 <[email protected]> > To: "[email protected]" <[email protected]> > 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:[email protected]] > Gesendet: Samstag, 22. Jänner 2011 00:28 > An: [email protected] > 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 <[email protected]> > To: [email protected] > 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 >
