jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raj <db.raj...@gmail.com>
Subject Re: AW: Concurrency issues after upgrading to 2.2 from 1.6
Date Mon, 24 Jan 2011 14:43:03 GMT
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.KOELL@TIROL.GV.AT>
> To: "users@jackrabbit.apache.org" <users@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 <shailesh.mangal@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message