Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CURATOR-351] Support for TTL Nodes #171

Merged
merged 16 commits into from Apr 25, 2017
Merged

[CURATOR-351] Support for TTL Nodes #171

merged 16 commits into from Apr 25, 2017

Conversation

Randgalt
Copy link
Member

Early PR for TTL nodes support so others can test.

Copy link
Contributor

@cammckenzie cammckenzie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The content looks fine to me, just a question about the tests.

client.start();

client.create().withTtl(10).creatingParentsIfNeeded().withMode(CreateMode.PERSISTENT_WITH_TTL).forPath("/a/b/c");
Thread.sleep(20);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that client should get a 'removed' event when the node times out and gets removed by ZK? If so, wouldn't it be less error prone to wait on a latch and checking that the node was deleted within 10 +- some fudge factor rather than just sleeping?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll take a look at that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On reflection, I want to verify that the node is deleted within the TTL so the sleep seems appropriate to me. Right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're probably right, my concern is that I don't know how quick ZK responds to these TTL expiry events. You've only got a 10ms window here for ZK to remove the node. Maybe that's enough.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know exactly how long because I wrote it :D Note at the top of the test class: System.setProperty("znode.container.checkIntervalMs", "1");

@@ -83,6 +85,13 @@ public CreateBuilderMain orSetData()
return this;
}

@Override
public CreateBuilderMain withTtl(long ttl)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer withTTL, but that's just personal preference. I'm not sure what the standard for capitalisation of acronyms is.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've started using strict camel case for everything. It's easier to remember. But, it's not a big deal to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to strict camel case. I don't like how it looks either, but I do like that it is more consistent.

@Randgalt
Copy link
Member Author

Randgalt commented Apr 3, 2017

FYI - TTL nodes will be in the next release of ZK (3.5.3-beta).

@Randgalt Randgalt changed the title [CURATOR-351] Support for TTL Nodes - NOT READY FOR MERGE YET!!! [CURATOR-351] Support for TTL Nodes Apr 17, 2017
@Randgalt
Copy link
Member Author

ZooKeeper 3.5.3-beta has been released with TTL support so this PR is now ready.

try (PersistentTtlNode node = new PersistentTtlNode(client, "/test", 10, new byte[0]))
{
node.start();
node.waitForInitialCreate(timing.session(), TimeUnit.MILLISECONDS);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably assert that the return is true?

@@ -44,25 +45,49 @@ public void testBasic() throws Exception
{
client.start();

try (PersistentTtlNode node = new PersistentTtlNode(client, "/test", 10, new byte[0]))
try (PersistentTtlNode node = new PersistentTtlNode(client, "/test", 100, new byte[0]))
{
node.start();
node.waitForInitialCreate(timing.session(), TimeUnit.MILLISECONDS);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably assert that the return is true?

@@ -18,8 +18,19 @@
*/
package org.apache.curator.framework.api;

public interface CreateBuilder extends
CreateBuilderMain
public interface CreateBuilder extends CreateBuilderMain
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not extend CreateBuilder2 here? Less duplicate code/comments for withTtl

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because of orSetData()

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. That's not a problem.

public interface CreateBuilder extends CreateBuilder2 { CreateBuilder2 orSetData() }

@@ -83,6 +85,13 @@ public CreateBuilderMain orSetData()
return this;
}

@Override
public CreateBuilderMain withTtl(long ttl)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to strict camel case. I don't like how it looks either, but I do like that it is more consistent.


/**
* @param client the client
* @param path path for the parent ZNode
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing javadoc for executor service. probably worthwhile to caution people that if the executor service is overloaded then it may impact the ability to do ttl updates. we should also give users a way to realize that this is the case when their nodes start expiring. probably not a very common use case though.

@asfgit asfgit merged commit 086c5b4 into CURATOR-3.0 Apr 25, 2017
@hubot hubot deleted the CURATOR-351 branch April 28, 2017 16:43
@asfgit asfgit restored the CURATOR-351 branch April 28, 2017 17:12
@tisonkun tisonkun deleted the CURATOR-351 branch March 13, 2023 07:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants