curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Jaton (JIRA)" <j...@apache.org>
Subject [jira] [Reopened] (CURATOR-268) Curator client doesn't behave well when it loses connection: CRUD operation fail
Date Fri, 02 Oct 2015 17:07:26 GMT

     [ 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)

Mime
View raw message