[
https://issues.apache.org/jira/browse/CURATOR-584?focusedWorklogId=545733&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-545733
]
ASF GitHub Bot logged work on CURATOR-584:
------------------------------------------
Author: ASF GitHub Bot
Created on: 02/Feb/21 02:04
Start Date: 02/Feb/21 02:04
Worklog Time Spent: 10m
Work Description: TisonKun commented on a change in pull request #376:
URL: https://github.com/apache/curator/pull/376#discussion_r568269227
##########
File path:
curator-framework/src/main/java/org/apache/curator/framework/imps/CreateBuilderImpl.java
##########
@@ -1147,12 +1235,35 @@ public String call() throws Exception
if ( setDataIfExists )
{
Stat setStat =
client.getZooKeeper().setData(path, data, setDataIfExistsVersion);
- if(storingStat != null)
+ if ( storingStat != null )
{
DataTree.copyStat(setStat,
storingStat);
}
createdPath = path;
}
+ else if ( idempotent &&
!createMode.isSequential() )
Review comment:
ditto warning suggestion here, or we can check whenever an operation
triggered.
##########
File path:
curator-framework/src/main/java/org/apache/curator/framework/imps/CreateBuilderImpl.java
##########
@@ -642,6 +657,10 @@ else if ( (rc ==
KeeperException.Code.NODEEXISTS.intValue()) && setDataIfExists
{
backgroundSetData(client, operationAndData,
operationAndData.getData().getPath(), backgrounding);
}
+ else if ( (rc ==
KeeperException.Code.NODEEXISTS.intValue()) && idempotent &&
!createMode.isSequential() )
Review comment:
Can we log a warning when user set `idempotent` with sequential node?
##########
File path:
curator-framework/src/main/java/org/apache/curator/framework/imps/CreateBuilderImpl.java
##########
@@ -87,6 +93,8 @@ public CreateBuilderImpl(CuratorFrameworkImpl client,
CreateMode createMode, Bac
this.createParentsAsContainers = createParentsAsContainers;
this.compress = compress;
this.setDataIfExists = setDataIfExists;
+ // TODO implement this in CURATOR-589
Review comment:
remove before merging
##########
File path: curator-examples/src/main/java/framework/CrudExamples.java
##########
@@ -119,6 +145,24 @@ public static void guaranteedDelete(CuratorFramework
client, String path) t
client.delete().guaranteed().forPath(path);
}
+ public static void idempotentDelete(CuratorFramework client, String
path, int currentVersion) throws Exception
Review comment:
nit: why not `deleteIdempotent`
##########
File path:
curator-framework/src/main/java/org/apache/curator/framework/imps/SetDataBuilderImpl.java
##########
@@ -210,6 +231,48 @@ public Stat forPath(String path) throws Exception
return this;
}
+ private void backgroundCheckIdempotent(final CuratorFrameworkImpl client,
final OperationAndData<PathAndBytes> mainOperationAndData, final String path,
final Backgrounding backgrounding)
+ {
+ final AsyncCallback.DataCallback dataCallback = new
AsyncCallback.DataCallback()
+ {
+ @Override
+ public void processResult(int rc, String path, Object ctx, byte[]
data, Stat stat)
+ {
+ if ( rc == KeeperException.Code.OK.intValue() )
+ {
+ if ( failNextIdempotentCheckForTesting )
+ {
+ failNextIdempotentCheckForTesting = false;
+ rc =
KeeperException.Code.CONNECTIONLOSS.intValue();
+ }
+ else if ( !idempotentSetMatches(stat.getVersion(),
mainOperationAndData.getData().getData(), data) )
+ {
+ rc = KeeperException.Code.BADVERSION.intValue();
+ }
+ }
+ CuratorEvent event = new CuratorEventImpl(client,
CuratorEventType.SET_DATA, rc, path, null, ctx, stat, null, null, null, null,
null);
Review comment:
```suggestion
final CuratorEvent event = new CuratorEventImpl(client,
CuratorEventType.SET_DATA, rc, path, null, ctx, stat, null, null, null, null,
null);
```
##########
File path:
curator-framework/src/main/java/org/apache/curator/framework/imps/SetDataBuilderImpl.java
##########
@@ -51,6 +63,8 @@ public SetDataBuilderImpl(CuratorFrameworkImpl client,
Backgrounding backgroundi
this.backgrounding = backgrounding;
this.version = version;
this.compress = compress;
+ // TODO implement this in CURATOR-589
Review comment:
ditto removal suggestion here.
##########
File path:
curator-framework/src/main/java/org/apache/curator/framework/imps/SetDataBuilderImpl.java
##########
@@ -36,13 +39,22 @@
private Backgrounding backgrounding;
private int version;
private boolean compress;
+ private boolean idempotent;
Review comment:
ditto default `false` suggest here.
##########
File path:
curator-framework/src/main/java/org/apache/curator/framework/imps/CreateBuilderImpl.java
##########
@@ -57,12 +57,17 @@
private boolean compress;
private boolean setDataIfExists;
private int setDataIfExistsVersion = -1;
+ private boolean idempotent;
Review comment:
how about just set a default `false` here?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 545733)
Time Spent: 4h 40m (was: 4.5h)
> Curator Client Fault Tolerance Extensions
> -----------------------------------------
>
> Key: CURATOR-584
> URL: https://issues.apache.org/jira/browse/CURATOR-584
> Project: Apache Curator
> Issue Type: Improvement
> Reporter: Josh Slocum
> Assignee: Jordan Zimmerman
> Priority: Minor
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Tl;dr My team at Indeed has developed ZooKeeper functionality to handle
> stateful retrying of connectionloss for write operations, and we wanted to
> reach out to discuss if this is something the Curator team may be interested
> in incorporating.
> We initially reached out to the Zookeeper team
> (https://issues.apache.org/jira/browse/ZOOKEEPER-3927) but were redirected to
> Curator as the better place to contribute them. The changes could be
> relatively easily added as additional parameters and/or extensions of the
> existing retry behavior in Curator's write operations.
>
> Hi Curator Devs,
> My team uses zookeeper extensively as part of a distributed key-value store
> we've built at Indeed (think HBase replacement). Due to our deployment setup
> co-locating our database daemons with our large hadoop cluster, and the
> network-intensive nature of a lot of our compute jobs, we were experiencing a
> large amount of transient ConnectionLoss issues. This was especially
> problematic on important write operations, such as the creation deletion of
> distributed locks/leases or updating distributed state in the cluster.
> We saw that some existing zookeeper client wrappers handled retrying in the
> presence of ConnectionLoss, but all of the ones we looked at (including
> Curator) didn't allow for retrying writes wiith all of the proper state.
> Consider the case of retrying a create. If the initial create had succeeded
> on the server, but the client got connectionloss, the client would get a
> NodeExists exception on the retried request, even though the znode was
> created. This resulted in many issues. For the distributed lock/lease
> example, to other nodes, it looked like the calling node had been successful
> acquiring the "lock", and to the calling node, it appeared that it was not
> able to acquire the "lock", which results in a deadlock.
> Curator has parameters that can modify the behavior upon retry, but those
> were not sufficient. For example, create() has orSetData(), and delete() has
> guaranteed().
> To solve this, we implemented a set of "connection-loss tolerant primitives"
> for the main types of write operations. They handle a connection loss by
> retrying the operation in a loop, but upon error cases in the retry, inspect
> the current state to see if it matches the case where a previous round that
> got connectionloss actually succeeded.
> * createRetriable(String path, byte[] data)
> * setDataRetriable(String path, byte[] newData, int currentVersion)
> * deleteRetriable(String path, int currentVersion)
> * compareAndDeleteRetriable(String path, byte[] currentData, int
> currentVersion)
> For example, in createRetriable, it will retry the create again on connection
> loss. If the retried call gets a NodeExists exception, it will check to see
> if (getData(path) == data and dataVersion == 0). If it does, it assumes the
> first create succeeded and returns success, otherwise it propagates the
> NodeExists exception.
> These primitives have allowed us to program our ZooKeeper layer as if
> ConnectionLoss isn't a transient state we have to worry about, since they
> have essentially the same guarantees as the non-retriable functions in the
> zookeeper api do (with a slight difference in semantics).
> Because these behaviors could be relatively easily added to Curator as
> additional parameters to the existing mechanisms, and (to my knowledge)
> aren't implemented anywhere else, we think it could be a useful contribution
> to the Curator project. If this isn't something that Curator is interested in
> incorporating, Indeed may also consider open sourcing it as a standalone
> library.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
