[
https://issues.apache.org/jira/browse/JCR-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434890#comment-13434890
]
Thomas Mueller commented on JCR-3406:
-------------------------------------
Please note the patch only applies to updateCancelled and updateCommitted. As
far as I see, those methods are called after updateCreated / updatePrepared,
and those two methods do test for status == STARTED (I didn't change that). So
I don't see how this could affect startup, but I might be wrong of course.
> I'm just afraid we might create some race condition on startup. The code
> seems to be designed to first trigger a sync() call before any other
> operations are done which seems correct to me.
Sorry I don't understand, the patch I made doesn't affect sync() as far as I
see. It is only supposed to ensure that the journal is unlocked if it was
locked.
It's quite hard to say if the patch would break something, just on a
theoretical basis (without test cases). I do have an upstream test case that
shows the current behavior is problematic, and the patch fixes that, so I
suggest I will commit my patch next week, unless somebody can come up with a
better patch, or a test case that shows my patch is problematic.
> Journal doUnlock sometimes not called on repository shutdown
> ------------------------------------------------------------
>
> Key: JCR-3406
> URL: https://issues.apache.org/jira/browse/JCR-3406
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
>
> When the repository is shut down, the method AbstractJournal.doUnlock(boolean
> successful) is sometimes not called. The method Journal.close is called, but
> when the journal implementation uses a reentrant lock it can't unlock because
> close is called from a different thread.
> The reason for not calling doUnlock is that ClusterNode.stop() sets the
> status to "stopped", which causes all WorkspaceUpdateChannel methods to not
> work, including updateCommitted and updateCancelled. Therefore, it is
> possible that an operation is started but never completed nor cancelled.
> To solve the issue, I found that it is enough to let updateCommitted and
> updateCancelled to complete, so that operations that are in progress can
> finish.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
