curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-326) createContainers fails silently if client is not connected
Date Sat, 21 May 2016 16:14:12 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295108#comment-15295108
] 

ASF GitHub Bot commented on CURATOR-326:
----------------------------------------

GitHub user Randgalt opened a pull request:

    https://github.com/apache/curator/pull/151

    [CURATOR-326] exists() with createParentContainersIfNeeded was ignoring too many KeeperExceptions

    exists() with createParentContainersIfNeeded was ignoring too many KeeperExceptions and
thus hiding connection problems. Should only ignore node exists/not-exists

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/apache/curator CURATOR-326

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/curator/pull/151.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #151
    
----
commit 47003e3e6b92ae7a3e41497ae10e99b860e10f87
Author: randgalt <randgalt@apache.org>
Date:   2016-05-21T16:12:28Z

    exists() with createParentContainersIfNeeded was ignoring too many KeeperExceptions and
thus hiding connection problems. Should only ignore node exists/not-exists

----


> createContainers fails silently if client is not connected
> ----------------------------------------------------------
>
>                 Key: CURATOR-326
>                 URL: https://issues.apache.org/jira/browse/CURATOR-326
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 3.1.0, 2.10.0
>            Reporter: Gerd Behrmann
>            Assignee: Jordan Zimmerman
>             Fix For: 2.10.1, 3.1.1
>
>
> Calling CuratorFramework#createContainers on a non-existing path while the client is
not yet connected to the server (e.g. server is down while client is starting) fails silently
if enough time goes by before the server is started. 
> The following unit test demonstrates the issue:
> {code:java}
> package dmg.cells.zookeeper;
> import org.apache.curator.framework.CuratorFramework;
> import org.apache.curator.framework.CuratorFrameworkFactory;
> import org.apache.curator.retry.RetryForever;
> import org.apache.curator.test.TestingServer;
> import org.apache.curator.test.Timing;
> import org.junit.Test;
> import static junit.framework.TestCase.assertNotNull;
> public class CuratorTest
> {
>     @Test
>     public void createContainersTest() throws Exception
>     {
>         TestingServer server = new TestingServer(false);
>         Timing timing = new Timing();
>         CuratorFramework client = CuratorFrameworkFactory.newClient(server.getConnectString(),
timing.session(), timing.connection(), new RetryForever(100));
>         try {
>             new Thread() {
>                 @Override
>                 public void run()
>                 {
>                     try {
>                         Thread.sleep(30000);
>                         server.start();
>                     } catch (Exception e) {
>                         e.printStackTrace();
>                     }
>                 }
>             }.start();
>             client.start();
>             client.createContainers("/this/does/not/exist");
>             assertNotNull(client.checkExists().forPath("/this/does/not/exist"));
>         } finally {
>             client.close();
>             server.stop();
>         }
>     }
> }
> {code}
> The delay before starting the server is significant. If only sleeping for 10 seconds,
the unit test passes. Sleeping for 30 seconds triggers a code path in Curator that will cause
CuratorFramework#createContainers to wait until the server is started, yet it returns without
exception and without creating the path. The assertion fails.
> I tracked down the issue to ExistingBuilderImpl#pathInForeground in which the call to
ZKPath#mkdirs is wrapped with a try-catch that ignores the exception. Thus the failed operation
is neither retried nor propagated.
> Specifically this causes silent problems with PathAndChildren cache as it uses EnsureContainer#ensure
during startup to ensure that the path exists. This internally calls the above createContainers.
When it fails silently, the recipe fails to register a watcher on the non-existing path and
consequently the cache stays empty even when the server finally is started and the path is
populated by another client.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message