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] [Resolved] (CURATOR-268) Curator client doesn't behave well when it loses connection: CRUD operation fail
Date Fri, 02 Oct 2015 16:32:26 GMT

     [ https://issues.apache.org/jira/browse/CURATOR-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Benjamin Jaton resolved CURATOR-268.
------------------------------------
    Resolution: Invalid

Thanks Jordan, you appear to be right.
I reproduce the bug without any Curator code, using the client thread and a fresh ZK server
3.5.1-alpha.
I will reach out to the ZK community.

> 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