stefan-egli commented on a change in pull request #243:
URL: https://github.com/apache/jackrabbit-oak/pull/243#discussion_r462161347
##########
File path:
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
##########
@@ -3160,6 +3187,22 @@ private void signalClusterStateChange() {
}
}
+ /**
+ * FOR TESTING ONLY :
+ * stops the backgroundUpdateThread (by overwriting its
+ * isDisposed flag) and optionally waits for the thread to
+ * terminate.
+ * @param timeoutMillis optional amount of millis to wait for the thread
to terminate at max
+ * @return true if thread is no longer running
+ */
+ boolean stopBackgroundUpdateThread(long timeoutMillis) throws
InterruptedException {
Review comment:
Nice, thx @fabriziofortino, I've added this now.
##########
File path:
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
##########
@@ -3160,6 +3187,22 @@ private void signalClusterStateChange() {
}
}
+ /**
+ * FOR TESTING ONLY :
+ * stops the backgroundUpdateThread (by overwriting its
+ * isDisposed flag) and optionally waits for the thread to
+ * terminate.
+ * @param timeoutMillis optional amount of millis to wait for the thread
to terminate at max
+ * @return true if thread is no longer running
+ */
+ boolean stopBackgroundUpdateThread(long timeoutMillis) throws
InterruptedException {
Review comment:
@jsedding interesting approach indeed. I think this might be something
we could look into. I'm wondering if it could be done in a separate ticket
though, as I think it could involve quite a bit of changes and would meanwhile
block progress on this? The concern I see with a thread-factory is that for
gracefully stopping the 'BackgroundUpdateOperation' (or the 'NodeStoreTask'
actually) one needs to hook into the 'NodeStoreTask.run' loop - and the current
patch does that by overwriting the 'isDisposed' in 'forceStop()'. The
thread-factory variant would still need to do that as well, one way or another,
I guess. So something like the suggested 'forceStop()' would still be necessary
I think. But the "ugly" 'stopBackgroundUpdateThread' would be gone, agreed.
Should I create a follow-up ticket for this (with the risk of that being
prioritized lower though, agreed)?
##########
File path:
oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java
##########
@@ -3160,6 +3187,22 @@ private void signalClusterStateChange() {
}
}
+ /**
+ * FOR TESTING ONLY :
+ * stops the backgroundUpdateThread (by overwriting its
+ * isDisposed flag) and optionally waits for the thread to
+ * terminate.
+ * @param timeoutMillis optional amount of millis to wait for the thread
to terminate at max
+ * @return true if thread is no longer running
+ */
+ boolean stopBackgroundUpdateThread(long timeoutMillis) throws
InterruptedException {
Review comment:
@jsedding interesting approach indeed. I think this might be something
we could look into. I'm wondering if it could be done in a separate ticket
though, as I think it could involve quite a bit of changes and would meanwhile
block progress on this? The concern I see with a thread-factory is that for
gracefully stopping the `BackgroundUpdateOperation` (or the `NodeStoreTask`
actually) one needs to hook into the `NodeStoreTask.run` loop - and the current
patch does that by overwriting the `isDisposed` in `forceStop()`. The
thread-factory variant would still need to do that as well, one way or another,
I guess. So something like the suggested `forceStop()` would still be necessary
I think. But the "ugly" `stopBackgroundUpdateThread` would be gone, agreed.
Should I create a follow-up ticket for this (with the risk of that being
prioritized lower though, agreed)?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
