[JCR-3417] Failed Journal lock not propagated

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.5, 1.6, 2.0, 2.1, 2.2, 2.3, 2.4
• Fix Version/s: 2.4.3, 2.5.2
• Component/s: jackrabbit-core
• Assignee: Marcel Reutegger
• Reporter: Marcel Reutegger
• Created: 27/Aug/12 14:10
• Updated: 27/Sep/12 07:34
• Resolved: 28/Aug/12 07:26

Description

Locking the journal when something is written to the repository happens through the UpdateEventChannel interface. A callstack will usually look like this:

at org.apache.jackrabbit.core.journal.AbstractJournal.lockAndSync(AbstractJournal.java:285)
at org.apache.jackrabbit.core.journal.DefaultRecordProducer.append(DefaultRecordProducer.java:51)
at org.apache.jackrabbit.core.cluster.ClusterNode$WorkspaceUpdateChannel.updateCreated(ClusterNode.java:598)
at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.begin(SharedItemStateManager.java:565)
at org.apache.jackrabbit.core.state.SharedItemStateManager.beginUpdate(SharedItemStateManager.java:1462)
at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1492)

The current implementation silently ignores any exception that happens inside e.g. UpdateEventChannel.updateCreated(Update) and proceeds with the update assuming everything is OK. This behaviour may lead to a deadlock when the Journal lock is later acquired again.

I suggest to update at least the updateCreated() method to throw a ClusterException and fail the Update in SharedItemStateManager with an ItemStateException in case the ClusterException is thrown.

Issue Links

• relates to: JCR-3432 Backport JCR-3417: Failed Journal lock not propagated