Github user srdo commented on the issue:
https://github.com/apache/curator/pull/215
Okay, I think I misunderstood your concern. I thought you were worried
about something like this
```
curatorClient.create().inBackground((client, event) -> {
//I thought your concern was that this code sometimes wouldn't run in the
EventThread
}).forPath(p)
```
Isn't your example code already broken?
```
class MyWatcher implements Watcher {
public void process(WatchedEvent event) {
curatorClient.create().inBackground().forPath(p);
//I'm assuming your concern is that code here may assume that the
path is now created?
}
}
```
If the surrounding code is depending on the create call running in the
foreground (in the EventThread), why is it using `inBackground`? It'll be
flaky any time there's a connection issue or a retry (in which case the create
operation was already being put on the background thread by
`performBackgroundOperation`).
Otherwise if the code isn't depending on the create call running in the
foreground, is there still an issue with the change?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
