You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Raj <db...@gmail.com> on 2011/01/05 17:19:14 UTC
Re: Jackrabbit 1.6.4 locking issue
Hi Everyone,
Any pointers would be helpful.
thanks in advance,
Rajeev
On Tue, Dec 21, 2010 at 1:51 PM, Raj <db...@gmail.com> wrote:
>
> hi All,
>
> I am facing deadlock in my web application, which am suspecting is due to
> JackRabbit.
> Any pointers to resolve this are welcome.
>
> Environment: JackRabbit 1.6.4 on Java 1.6.0_18 (32bit, windows 7 64bit).
> Webapp is deployed under tomcat 5.5.28
>
> There are 3 user operations initiated sequentially with 4-5 seconds delay.
> All the 3 operations are similar in nature, they first read data from
> jackrabbit repo and copy that data.
>
> http-80-Processor18 - 1st operation,
> http-80-Processor19 - 2nd
> http-80-Processor25 - is 3rd.
>
> Relevant thread dump is posted below.
>
> Questions/Observations -
> Q1: processor 18 is waiting for lock 0x0c9ffda8 when it has already
> acquired it !
> Q2: processor 19 is waiting for 0x0c9de878 while it is already acquired by
> processor 25.
> Q3: processor 25 is waiting for lock 0x0c9ffd98 when it has already
> acquired it !
>
> regards,
> Rajeev
>
> thread dump
> ====================================================
> "http-80-Processor18"
> daemon
> prio=6 tid=0x3c80c000
> nid=0xce0
> in Object.wait()
> [0x41e9d000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0c9ffda8>
> (a
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
> at java.lang.Object.wait(Object.java:485)
> at
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock.acquire(Unknown
> Source)
> - locked <0x0c9ffda8>
> (a
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$WriterLock)
> at
> org.apache.jackrabbit.core.state.DefaultISMLocking$WriteLockImpl.<init>(DefaultISMLocking.java:76)
> at
> org.apache.jackrabbit.core.state.DefaultISMLocking$WriteLockImpl.<init>(DefaultISMLocking.java:70)
> at
> org.apache.jackrabbit.core.state.DefaultISMLocking.acquireWriteLock(DefaultISMLocking.java:64)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.acquireWriteLock(SharedItemStateManager.java:1836)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.access$200(SharedItemStateManager.java:116)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:558)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1473)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1503)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
> at
> org.apache.jackrabbit.core.BatchedItemOperations.update(BatchedItemOperations.java:155)
> at
> org.apache.jackrabbit.core.WorkspaceImpl.internalCopy(WorkspaceImpl.java:448)
> at
> org.apache.jackrabbit.core.WorkspaceImpl.copy(WorkspaceImpl.java:666)
> at
> com.thed.repository.TestcaseContentsManager.copyTestCases(TestcaseContentsManager.java:354)
>
> ====================================================
> "http-80-Processor19"
> daemon
> prio=6 tid=0x3c80c400
> nid=0x15e0
> waiting for monitor entry
> [0x41f2d000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:167)
> - waiting to lock <0x0c9de878>
> (a org.apache.jackrabbit.core.state.LocalItemStateManager)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:198)
> at
> org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:352)
> at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:298)
> at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:562)
> - locked <0x0c9de2c8>
> (a org.apache.jackrabbit.core.ItemManager)
> at
> org.apache.jackrabbit.core.lock.LockManagerImpl.refresh(LockManagerImpl.java:1092)
> at
> org.apache.jackrabbit.core.lock.LockManagerImpl.nodeAdded(LockManagerImpl.java:1122)
> at
> org.apache.jackrabbit.core.lock.LockManagerImpl.onEvent(LockManagerImpl.java:1025)
> at
> org.apache.jackrabbit.core.observation.EventConsumer.consumeEvents(EventConsumer.java:244)
> at
> org.apache.jackrabbit.core.observation.ObservationDispatcher.dispatchEvents(ObservationDispatcher.java:201)
> at
> org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventStateCollection.java:474)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:780)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1503)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326)
> at
> org.apache.jackrabbit.core.BatchedItemOperations.update(BatchedItemOperations.java:155)
> at
> org.apache.jackrabbit.core.WorkspaceImpl.internalCopy(WorkspaceImpl.java:448)
> at
> org.apache.jackrabbit.core.WorkspaceImpl.copy(WorkspaceImpl.java:666)
>
> ====================================================
>
> "http-80-Processor25"
> daemon
> prio=6 tid=0x3c80e800
> nid=0xb10
> in Object.wait()
> [0x4228d000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0c9ffd98>
> (a
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
> at java.lang.Object.wait(Object.java:485)
> at
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock.acquire(Unknown
> Source)
> - locked <0x0c9ffd98>
> (a
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
> at
> org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:102)
> at
> org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:96)
> at
> org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:53)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1822)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:253)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:107)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:172)
> - locked <0x0c9de878>
> (a org.apache.jackrabbit.core.state.LocalItemStateManager)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:198)
> at
> org.apache.jackrabbit.core.HierarchyManagerImpl.getItemState(HierarchyManagerImpl.java:150)
> at
> org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManagerImpl.java:393)
> at
> org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierarchyManager.java:229)
> at
> org.apache.jackrabbit.core.lock.LockManagerImpl.getPath(LockManagerImpl.java:751)
> at
> org.apache.jackrabbit.core.lock.LockManagerImpl.getLockInfo(LockManagerImpl.java:486)
>
>
Re: Jackrabbit 1.6.4 locking issue
Posted by luciano favaro <lu...@gmail.com>.
Hi Guys, I'm facing similar problem, since I have a custom login module that
uses same systemsession on all .login, do you have any update on this issue?
Thanks,
Luciano
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Jackrabbit-1-6-4-locking-issue-tp3134490p4658778.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Jackrabbit 1.6.4 locking issue
Posted by Jukka Zitting <jz...@adobe.com>.
Hi,
On 02/14/2011 10:40 AM, Raj wrote:
> The stack traces match a lot, I strongly believe it may be same issue.
OK, thanks for the verification!
> Please let me know if this bug could be addressed soon.
> I would love to try any fixes in my setup.
Excellent, thanks. I'll see what we can do about this on a short notice.
This deadlock is related to security code and synchronization of
concurrent sessions, both of which are areas on which we have been
working with for Jackrabbit 2.2. One thing you might want to try is
switching back to 2.1 to see if this deadlock also occurs there.
Also, it would be perfect if you could somehow narrow down the deadlock
you're seeing into a standalone test case. I currently don't have a way
to reliably reproduce the issue locally, which makes it harder to fix it.
--
Jukka Zitting
Re: Jackrabbit 1.6.4 locking issue
Posted by Raj <db...@gmail.com>.
hi Jukka,
Thanks for your reply.
The stack traces match a lot, I strongly believe it may be same issue.
Our setup doesn't use lucene and acl and we use workspace.copy, so stack
traces won't match perfectly and jackrabbit versions are different too.
Ignoring bottom 3-4 items in my stack trace, it appears control flow seems
to be taking identical steps.
Thread 19 -> matches stack trace A (as per bug report)
Thread 18 -> matches B
Thread 25 -> matches C
Please let me know if this bug could be addressed soon.
I would love to try any fixes in my setup.
thanks for your help.
cheers,
Rajeev
On Fri, Feb 11, 2011 at 11:52 PM, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> On Wed, Jan 5, 2011 at 9:16 PM, shailesh mangal
> <sh...@getzephyr.com> wrote:
> > Unfortunately issue still exists, even after we moved to 2.2.
>
> Do you still see this problem in your deployment?
>
> I found a somewhat similar (though not exactly the same) deadlock
> scenario with the latest trunk, see JCR-890 [1]. It would be great if
> you could check if the stacktraces match your case.
>
> I don't believe the original deadlock case described for 1.6.4 can
> occur anymore in 2.2.
>
> [1] https://issues.apache.org/jira/browse/JCR-2890
>
> BR,
>
> Jukka Zitting
>
Re: Jackrabbit 1.6.4 locking issue
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Jan 5, 2011 at 9:16 PM, shailesh mangal
<sh...@getzephyr.com> wrote:
> Unfortunately issue still exists, even after we moved to 2.2.
Do you still see this problem in your deployment?
I found a somewhat similar (though not exactly the same) deadlock
scenario with the latest trunk, see JCR-890 [1]. It would be great if
you could check if the stacktraces match your case.
I don't believe the original deadlock case described for 1.6.4 can
occur anymore in 2.2.
[1] https://issues.apache.org/jira/browse/JCR-2890
BR,
Jukka Zitting
Re: Jackrabbit 1.6.4 locking issue
Posted by shailesh mangal <sh...@getzephyr.com>.
Unfortunately issue still exists, even after we moved to 2.2. here is my
original post.
http://dev.day.com/discussion-groups/content/lists/jackrabbit-users/2010-12/2010-12-29_Concurrency_issues_after_upgrading_to_2_2_from_1_6_shailesh_mangal.html
In our use case, we allow bulk operations where multiple users add nodes to the
same parent. Each user request runs on its own thread and doesnt share the
session (common authentication credentials though).
We are very hard pressed to fix this issue and considering all alternatives at
this point. Any help is highly appreciated.
-Shailesh
________________________________
From: Jukka Zitting <ju...@gmail.com>
To: users@jackrabbit.apache.org
Sent: Wed, January 5, 2011 8:32:07 AM
Subject: Re: Jackrabbit 1.6.4 locking issue
Hi,
On Wed, Jan 5, 2011 at 5:19 PM, Raj <db...@gmail.com> wrote:
> Any pointers would be helpful.
This seems like one deadlock scenario I fixed as a part of JCR-2699
[1]. Can you check if the problem still occurs with the latest 2.x
releases?
See also JCR-2791 [2] for some relevant followup discussion.
[1] https://issues.apache.org/jira/browse/JCR-2699
[2] https://issues.apache.org/jira/browse/JCR-2791
BR,
Jukka Zitting
Re: Jackrabbit 1.6.4 locking issue
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Jan 5, 2011 at 5:19 PM, Raj <db...@gmail.com> wrote:
> Any pointers would be helpful.
This seems like one deadlock scenario I fixed as a part of JCR-2699
[1]. Can you check if the problem still occurs with the latest 2.x
releases?
See also JCR-2791 [2] for some relevant followup discussion.
[1] https://issues.apache.org/jira/browse/JCR-2699
[2] https://issues.apache.org/jira/browse/JCR-2791
BR,
Jukka Zitting