CURATOR-727: Allow watches to be executed asynchronously #514
Conversation
| } | ||
| }; | ||
| } | ||
| if (watchRunnable != null) { |
There was a problem hiding this comment.
Perhaps more elegant to add an "else" that returns. Therefore, watchRunnable could be final non-null; no condition to act on it's null-ness.
| @@ -445,6 +447,18 @@ public void close() { | |||
| unhandledErrorListeners.clear(); | |||
| connectionStateManager.close(); | |||
| client.close(); | |||
|
|
|||
| if (asyncWatchService != null) { | |||
There was a problem hiding this comment.
If one of those long-running processes interacts with curator, I could see it failing. It'd be better to have close() relatively early call shutdown(), after publishing the close event.
There was a problem hiding this comment.
If the "asyncExecutor" could in fact always be pre-initialized to a "direct" (same thread Executor like Guava MoreExecutors.newDirectExecutorService), then there'd be no branching check around if it's present or not. Solr uses this technique in SimpleFacets too. That said, there's little complexity here so I'm not going to recommend it.
https://issues.apache.org/jira/browse/CURATOR-727
This gives users the ability to run all watches asynchronously, via a provided executorService.