[
https://issues.apache.org/jira/browse/CURATOR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027896#comment-16027896
]
ASF GitHub Bot commented on CURATOR-106:
----------------------------------------
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?
> Issuing a guaranteed delete can cause stack overflow if ZK is not reachable
> ---------------------------------------------------------------------------
>
> Key: CURATOR-106
> URL: https://issues.apache.org/jira/browse/CURATOR-106
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 2.4.2
> Reporter: Jasdeep Hundal
> Fix For: awaiting-response
>
>
> For guaranteed deletes (eg. lock releases) that fail, the FailedDeleteManager
> issues another guaranteed delete here:
> https://github.com/apache/curator/blob/master/curator-framework/src/main/java/org/apache/curator/framework/imps/FailedDeleteManager.java#L35
> In an environment where ZK has the potential to be down for an extended
> period of time, this has the potential to recurse until there is a stack
> overflow (particularly if the application is using multiple locks.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
