[
https://issues.apache.org/jira/browse/CURATOR-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Jaton reopened CURATOR-268:
------------------------------------
>From the ZK developers:
"The behavior is expected. If your client loses its connection, then you don't
know if the operation has gone through or not. When it reconnects, you can
check if it exists and possibly delete it, depending on the behavior you want
for you application."
Since Curator reason to exist is to shield the user from the
disconnections/retries, shouldn't Curator handle this scenario?
> Curator client doesn't behave well when it loses connection: CRUD operation
> fail
> --------------------------------------------------------------------------------
>
> Key: CURATOR-268
> URL: https://issues.apache.org/jira/browse/CURATOR-268
> Project: Apache Curator
> Issue Type: Bug
> Components: Client
> Affects Versions: 2.7.1, 2.9.0
> Reporter: Benjamin Jaton
> Priority: Critical
> Attachments: TestCuratorSaveConnLoss.java
>
>
> I am doing a basic stress test :
> - a TestingServer that keeps restarting in one thread
> - a Curator client that keeps creating/deleting a node in another
> After a few seconds, ether the create or the delete fail:
> {code}Thu Oct 01 15:35:10 PDT 2015 - Node /test has successfully been removed.
> Thu Oct 01 15:35:10 PDT 2015 - Recreating /test
> Thu Oct 01 15:35:10 PDT 2015 - Restarting server...
> Thu Oct 01 15:35:14 PDT 2015 - Restarting server...
> Thu Oct 01 15:35:15 PDT 2015 - ERROR: node should be removed.
> Thu Oct 01 15:35:15 PDT 2015 - Data of node is: test
> Node has been mysteriously created...
> org.apache.zookeeper.KeeperException$NodeExistsException: KeeperErrorCode =
> NodeExists for /test
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:123)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:1209)
> at
> org.apache.curator.framework.imps.CreateBuilderImpl$11.call(CreateBuilderImpl.java:720)
> at
> org.apache.curator.framework.imps.CreateBuilderImpl$11.call(CreateBuilderImpl.java:703)
> at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:107)
> at
> org.apache.curator.framework.imps.CreateBuilderImpl.pathInForeground(CreateBuilderImpl.java:700)
> at
> org.apache.curator.framework.imps.CreateBuilderImpl.protectedPathInForeground(CreateBuilderImpl.java:477)
> at
> org.apache.curator.framework.imps.CreateBuilderImpl.forPath(CreateBuilderImpl.java:467)
> at
> org.apache.curator.framework.imps.CreateBuilderImpl.forPath(CreateBuilderImpl.java:44)
> at TestCuratorSaveConnLoss$3.run(TestCuratorSaveConnLoss.java:87){code}
> The create shouldn't fail, we're within 5 seconds of the create and the
> connection timeout is 10 secs.
> This is surprising as this basic scenario is - AFAIK - the reason Curator
> exists in the first place.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
