[
https://issues.apache.org/jira/browse/JCR-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679159#action_12679159
]
Jukka Zitting commented on JCR-2000:
------------------------------------
The last problem appears to be an extra synchronization block in
LocalItemStateManager, which prevents the SearchManager from accessing content
when synchronous observation events are received. The relevant parts of the
thread dump are:
"Thread-605" prio=10 tid=0xa6d8e400 nid=0xdba waiting for monitor entry
[0xa430c000..0xa430cfa0]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:153)
- waiting to lock <0xad21eda0> (a
org.apache.jackrabbit.core.state.LocalItemStateManager)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:182)
at
org.apache.jackrabbit.core.SearchManager$1.nextNodeState(SearchManager.java:442)
at
org.apache.jackrabbit.core.SearchManager$1.next(SearchManager.java:435)
at
org.apache.commons.collections.iterators.TransformIterator.next(TransformIterator.java:87)
at
org.apache.commons.collections.IteratorUtils.toList(IteratorUtils.java:829)
at
org.apache.commons.collections.IteratorUtils.toList(IteratorUtils.java:805)
at
org.apache.jackrabbit.core.query.lucene.SearchIndex.updateNodes(SearchIndex.java:588)
at
org.apache.jackrabbit.core.SearchManager.onEvent(SearchManager.java:478)
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:447)
at
org.apache.jackrabbit.core.observation.DelegatingObservationDispatcher.dispatch(DelegatingObservationDispatcher.java:127)
at
org.apache.jackrabbit.core.observation.DelegatingObservationDispatcher.dispatchEvents(DelegatingObservationDispatcher.java:99)
at
org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventStateCollection.java:447)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:749)
at
org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:172)
at
org.apache.jackrabbit.core.version.XAVersionManager.commit(XAVersionManager.java:497)
at
org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:206)
- locked <0xb3b33ea0> (a org.apache.jackrabbit.core.TransactionContext)
at
org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:346)
at
org.apache.jackrabbit.core.UserTransactionImpl.commit(UserTransactionImpl.java:150)
at
org.apache.jackrabbit.core.ConcurrentVersioningWithTransactionsTest$1.execute(ConcurrentVersioningWithTransactionsTest.java:86)
at
org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:164)
at java.lang.Thread.run(Thread.java:619)
"Thread-604" prio=10 tid=0xa6d8d400 nid=0xdb9 in Object.wait()
[0xa435d000..0xa435e020]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xad159240> (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 <0xad159240> (a
EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLock)
at
org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:96)
at
org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(DefaultISMLocking.java:89)
at
org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(DefaultISMLocking.java:51)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(SharedItemStateManager.java:1416)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:253)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:93)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:158)
- locked <0xad21eda0> (a
org.apache.jackrabbit.core.state.LocalItemStateManager)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:182)
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:701)
at
org.apache.jackrabbit.core.lock.LockManagerImpl.getLockInfo(LockManagerImpl.java:439)
at
org.apache.jackrabbit.core.lock.XAEnvironment.getLockInfo(XAEnvironment.java:234)
at
org.apache.jackrabbit.core.lock.XALockManager.checkLock(XALockManager.java:184)
at
org.apache.jackrabbit.core.ItemValidator.checkLock(ItemValidator.java:382)
at
org.apache.jackrabbit.core.ItemValidator.checkCondition(ItemValidator.java:305)
at
org.apache.jackrabbit.core.ItemValidator.checkModify(ItemValidator.java:267)
at
org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:726)
at
org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:683)
at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:2055)
- locked <0xb3be44a0> (a org.apache.jackrabbit.core.NodeImpl)
at
org.apache.jackrabbit.core.ConcurrentVersioningWithTransactionsTest$1.execute(ConcurrentVersioningWithTransactionsTest.java:83)
at
org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:164)
at java.lang.Thread.run(Thread.java:619)
I'm not sure yet why the SearchManager is accessing a *LocalItemStateManager*
here, it should only ever access the SharedItemStateManager instance.
> Deadlock on concurrent commits
> ------------------------------
>
> Key: JCR-2000
> URL: https://issues.apache.org/jira/browse/JCR-2000
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, transactions
> Affects Versions: 1.5.3
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 1.5.4
>
> Attachments: JCR-2000.patch, JCR-2000.patch, thread-join.patch
>
>
> As reported in the followup to JCR-1979, there's a case where two
> transactions may be concurrently inside a commit. This is bad as it breaks
> the main assumption in http://jackrabbit.apache.org/concurrency-control.html
> about all transactions first acquiring the versioning write lock.
> Looking deeper into this I find that the versioning write lock is only
> acquired if the transaction being committed contains versioning operations.
> This is incorrect as all transactions in any case need to access the version
> store when checking for references.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
