[ 
https://issues.apache.org/jira/browse/OAK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632033#comment-15632033
 ] 

Chetan Mehrotra commented on OAK-3952:
--------------------------------------

What I mean here is that Observer close has 2 options

# It should wait for existing entries in queue to get processed 
# Or it cleans the queue and then wait for any existing processing to get 
complete 
# Or it discard everything and closes down without waiting for ongoing 
processing to complete -

Here #3 is current behaviour. Patch is for #2. 

For #1 we can decide if we should support it and if support then should it be 
done on opt in basis. Some listener is just interested in change to update the 
in memory state. So loosing event would not harm and makes no sense to have 
that listener go through change at time of shutdown. 

However some listener which is doing some state change like creating new node 
that would suffer if events are flushed like this and that can indicate that it 
should be be given time to complete the processing

> 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.6
>
>         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)

Reply via email to