[
https://issues.apache.org/jira/browse/OAK-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14716331#comment-14716331
]
Michael Dürig edited comment on OAK-3303 at 8/28/15 10:50 AM:
--------------------------------------------------------------
One scenario when this might happen is when the _interval_ value on the
_BackgroundThread_ is initialized after the #run method gets executed, so the
thread would end up in calling wait(0) aka. forever blocking.
Options discussed with [~mduerig] offline to improve the _BackgroundThread_
impl is to take the call to the Thread#start method out of the constructor.
I'd like to add actually throwing an error when the _interval_ value is 0
(should never happen).
was (Author: alex.parvulescu):
One scenario when this might happen is when the _interval_ value on the
_BackgroundThread_ is initialized after the #run method gets executed, so the
thread would end up in calling wait(0) aka. forever blocking.
Options discussed with [~mduerig] offline to improve the _BackgroundThread_
impl is to take the #run method out of the constructor.
I'd like to add actually throwing an error when the _interval_ value is 0
(should never happen).
> FileStore flush thread can get stuck
> ------------------------------------
>
> Key: OAK-3303
> URL: https://issues.apache.org/jira/browse/OAK-3303
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Fix For: 1.3.6
>
>
> In some very rare circumstances the flush thread was seen as possibly stuck
> for a while following a restart of the system. This results in data loss on
> restart (the system will roll back to the latest persisted revision on
> restart), and worse off there's no way of extracting the latest head revision
> using the tar files, so recovery is not (yet) possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)