Marcel Reutegger created JCR-3417:
-------------------------------------
Summary: Failed Journal lock not propagated
Key: JCR-3417
URL: https://issues.apache.org/jira/browse/JCR-3417
Project: Jackrabbit Content Repository
Issue Type: Bug
Affects Versions: 2.4, 2.3, 2.2, 2.1, 2.0, 1.6, 1.5
Reporter: Marcel Reutegger
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
