[
https://issues.apache.org/jira/browse/OAK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123317#comment-15123317
]
Michael Dürig commented on OAK-3952:
------------------------------------
I don't think we should tinker with the semantics of the {{close}} method. This
will most likely introduce regressions elsewhere. After all the current
behaviour was explicitly introduced (e.g. because of OAK-1176).
Furthermore the (arbitrary) time out will cause delays in shut down, which in
itself has been reported as an issue in the past AFAIR.
In the end it is the responsibility of the caller to call {{close}} at an
appropriate time coordinating with whatever listeners there still might be.
(Quite similar to stopping threads actually). What we could do is to add APIs
for callers to explicitly sync on stop. E.g. {{join(timeout)}}.
> BackgroundObserver close should wait for stop to be processed
> -------------------------------------------------------------
>
> Key: OAK-3952
> URL: https://issues.apache.org/jira/browse/OAK-3952
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Priority: Minor
> Fix For: 1.4
>
> Attachments: OAK-3952-v1.patch
>
>
> {{BackgroundObserver}} close method currently says that it does not wait for
> thread to finish. This can lead to situation when during shutdown the backing
> {{NodeStore}} goes away while the background thread is still busy with diff
> and that would lead to exceptions in the log.
> As being done in OAK-3923 the close call should wait for {{STOP}} signal to
> be processed before returning from close call.
> On side note we should also provide an option where the close call should
> wait for the queue to be processed instead of just silently clearing the
> queue which can lead to potential loss of important local events. Note that
> can happen for proper ordered shutdown!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
