[ https://issues.apache.org/jira/browse/JCR-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653434#comment-14653434 ]
Alex Parvulescu commented on JCR-3888: -------------------------------------- this commit looks like it introduced a regression: {code} Running org.apache.jackrabbit.core.query.lucene.TestAll Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.06 sec <<< FAILURE! - in org.apache.jackrabbit.core.query.lucene.TestAll testInitialIndex(org.apache.jackrabbit.core.query.lucene.IndexingQueueTest) Time elapsed: 0.309 sec <<< FAILURE! junit.framework.AssertionFailedError: expected:<110> but was:<0> at junit.framework.Assert.fail(Assert.java:50) at junit.framework.Assert.failNotEquals(Assert.java:287) at junit.framework.Assert.assertEquals(Assert.java:67) at junit.framework.Assert.assertEquals(Assert.java:134) at junit.framework.Assert.assertEquals(Assert.java:140) at org.apache.jackrabbit.core.query.lucene.IndexingQueueTest.testInitialIndex(IndexingQueueTest.java:128) {code} > Possible dead lock in SharedItemStateManager in clustered environment > --------------------------------------------------------------------- > > Key: JCR-3888 > URL: https://issues.apache.org/jira/browse/JCR-3888 > Project: Jackrabbit Content Repository > Issue Type: Bug > Affects Versions: 2.10.1 > Reporter: Unico Hommes > Assignee: Unico Hommes > Fix For: 2.10.2 > > > When using clustering SharedItemStateManager#Update#begin sets a lock on the > database (line 573) and subsequently a write lock is set (line 579): > {code:java} > // let listener know about change > try { > eventChannel.updateCreated(this); // line 573 > } catch (ClusterException e) { > throw new ItemStateException(e.getMessage(), e); > } > try { > writeLock = acquireWriteLock(local); // line 579 > } finally { > if (writeLock == null) { > eventChannel.updateCancelled(this); // line 582 > } > } > {code} > In SharedItemStateManager#Update#end the update is committed and the write > lock released: > {code:java} > eventChannel.updateCommitted(this, path); // line 849 > setAttribute(ATTRIBUTE_UPDATE_SIZE, null); > if (writeLock != null) { > // exception occurred before downgrading lock > writeLock.release(); > writeLock = null; > } else if (readLock != null) { > try { > if (succeeded) { > /* dispatch the events */ > events.dispatch(); > } > } finally { > readLock.release(); // 863 > } > } > {code} > However, the implementation of eventChannel#updateCommitted in > ClusterNode#WorkspaceUpdateChannel#updateCommitted has the following code: > {code:java} > long journalUpdateSize = record.update(); // line 700 > long recordRevision = record.getRevision(); > setRevision(recordRevision); // line 703 > {code} > The database lock is freed during the call to update the record on line 700. > If a contending thread now sets a database lock at SharedItemStateManager:573 > before this thread can set the revision in the database at ClusterNode:703 we > have a dead lock. This is because this thread holds the write lock in > SharedItemStateManager causing the contending thread to wait at > SharedItemStateManager:579 while the contending thread holds the database > lock causing this thread to wait at ClusterNode:703 -- This message was sent by Atlassian JIRA (v6.3.4#6332)