ctubbsii commented on a change in pull request #2169:
URL: https://github.com/apache/accumulo/pull/2169#discussion_r654123699
##########
File path:
core/src/main/java/org/apache/accumulo/core/clientImpl/TableOperationsImpl.java
##########
@@ -728,6 +728,7 @@ public void delete(String tableName)
List<ByteBuffer> args =
Arrays.asList(ByteBuffer.wrap(tableName.getBytes(UTF_8)));
Map<String,String> opts = new HashMap<>();
try {
+ cancelCompaction(tableName);
Review comment:
> If the cancelCompaction never returns and the delete never gets
submitted I don't think there is any harm here.
I disagree with this strongly.
Specifically, I'm concerned about the impact on user experience for
injecting another client-server RPC call and series of ZK operations in the
pipeline prior to the user's intent to delete the table being recorded as a new
FaTE. If anything happens in that pipeline that hangs, the user's intent to
delete the table is never recorded... and that could be very frustrating....
like hitting the button on a crosswalk or elevator and nothing happening.
This could be especially frustrating because the user may be deleting as a
consequence of prior table failures, and delete is being done as a last resort
for recovery (or as the easiest resort, in the case of tables a user considers
disposable). Because delete is so destructive, it is often used as a hammer
when a table is in such a bad state as to need starting over. Having another
operation precede it means that there are additional failure points that can
prevent this hammer from being swung.
As for the earlier question:
> how many tables are being deleted concurrently?
I know of some users who create and delete tables at a pace most would
consider extreme. I'm not sure how these changes would impact them.
##########
File path:
core/src/main/java/org/apache/accumulo/core/clientImpl/TableOperationsImpl.java
##########
@@ -728,6 +728,7 @@ public void delete(String tableName)
List<ByteBuffer> args =
Arrays.asList(ByteBuffer.wrap(tableName.getBytes(UTF_8)));
Map<String,String> opts = new HashMap<>();
try {
+ cancelCompaction(tableName);
Review comment:
Since all we're doing is using the read lock to update a ZK entry, I'm
wondering if we can reduce the number of intermediate operations by performing
this step early in the delete FaTE RepOs, rather than doing this client side.
Can't the delete table RepO get the read lock first, update the ZK entry, then
wait on the write lock?
--
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]
