[
https://issues.apache.org/jira/browse/CURATOR-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685957#comment-16685957
]
ASF GitHub Bot commented on CURATOR-483:
----------------------------------------
Github user cammckenzie commented on a diff in the pull request:
https://github.com/apache/curator/pull/281#discussion_r233280744
--- Diff:
curator-recipes/src/main/java/org/apache/curator/framework/recipes/nodes/PersistentNode.java
---
@@ -445,7 +445,8 @@ private void createNode()
try
{
String existingPath = nodePath.get();
- String createPath = (existingPath != null && !useProtection) ?
existingPath : basePath;
+ String createPath = existingPath == null || (useProtection &&
!isSequential(mode)) ? basePath
+ : (useProtection ? basePath +
existingPath.substring(existingPath.length()-10) : existingPath);
--- End diff --
Good question @njhill I don't really have a super strong preference, but
I'd prefer that the constant defining the size of the sequential bit is not in
the PersisteNode class. Perhaps just have a method in ZKPaths that extracts the
last 10 digits without any checks. We can make it more defensive down the track
if it gets used elsewhere.
I don't think that efficiency is a huge concern here as it's only going to
happen when the node is created.
> Sequential PersistentNodes with protection don't resync after reconnection
> --------------------------------------------------------------------------
>
> Key: CURATOR-483
> URL: https://issues.apache.org/jira/browse/CURATOR-483
> Project: Apache Curator
> Issue Type: Bug
> Components: Recipes
> Affects Versions: 4.0.1
> Reporter: Nick Hill
> Priority: Major
>
> When using a {{PersistentNode}} with a sequential creation mode (in my case
> ephemeral but I think persistent would be the same) and "protection" turned
> on, unexpected duplicate znodes get created upon reconnection after a
> disconnect (without the sequence suffix), rather than it just taking
> ownership of the previously created znode.
> I tracked down the cause of this and have made a simple fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
