[
https://issues.apache.org/jira/browse/CURATOR-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685828#comment-16685828
]
ASF GitHub Bot commented on CURATOR-483:
----------------------------------------
Github user njhill commented on a diff in the pull request:
https://github.com/apache/curator/pull/281#discussion_r233243506
--- 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 --
@Randgalt @cammckenzie sure, I can do that but am wondering about the best
semantics for such a utility method. In particular should it first verify that
the path ends in 10 digits? (even in the case that it does, I don't think it's
guaranteed to be a sequential node). If so and it does not end in 10 digits,
what should be the behaviour?
For this scenario in `PersistentNode` we can be "sure" that it's sequential
and hence it's probably reasonable (and more efficient) to omit the check.
Given that curator has lasted this long without the need for such a method, I'm
wondering whether having it is really warranted. Might it be better to wait
until N > 1 (if that ever happens)?
> 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)
