Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.5, 1.6, 2.0, 2.1, 2.2, 2.3, 2.4
-
None
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.
Attachments
Attachments
Issue Links
- relates to
-
JCR-3432 Backport JCR-3417: Failed Journal lock not propagated
- Closed