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/01/22 00:28:04 UTC
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
Concurrency issues in 2.2.1: DefaultISMLocking.releaseReadLock(DefaultISMLocking.java:140)
Posted by shailesh mangal <sh...@getzephyr.com>.
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
>
Re: AW: Concurrency issues after upgrading to 2.2 from 1.6
Posted by Raj <db...@gmail.com>.
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
>
Re: AW: Concurrency issues after upgrading to 2.2 from 1.6
Posted by shailesh mangal <sh...@getzephyr.com>.
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
AW: Concurrency issues after upgrading to 2.2 from 1.6
Posted by KÖLL Claus <C....@TIROL.GV.AT>.
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