You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by GitBox <gi...@apache.org> on 2022/12/07 06:33:02 UTC

[GitHub] [accumulo] ctubbsii commented on a diff in pull request #3091: Added code and tests to confirm ScanServers can scan offline tables

ctubbsii commented on code in PR #3091:
URL: https://github.com/apache/accumulo/pull/3091#discussion_r1041807613


##########
core/src/main/java/org/apache/accumulo/core/data/RangedObject.java:
##########
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   https://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.accumulo.core.data;
+
+/**
+ * Marker interface that declares the object is a type that represents a range
+ */
+public interface RangedObject<T> {

Review Comment:
   I'm not sure this interface makes sense to add. Although it's helpful to have a similar method on the `Range` class and `KeyExtent` because they serve similar roles in our public API and internal implementation, respectively, they are not closely related enough to require an interface to try to make them related. The need to use a generic type for its argument reveals how distantly related they are, as well as the fact that they have independent implementations, and we never assign either to any variable of the interface type for any purpose.
   
   I think it is sufficient to add the `overlaps` method to `Range` (with a corresponding `@since` tag on the new method) without adding this interface to the public API.



##########
core/src/main/java/org/apache/accumulo/core/clientImpl/ScannerImpl.java:
##########
@@ -152,6 +153,16 @@ public synchronized int getBatchSize() {
   @Override
   public synchronized Iterator<Entry<Key,Value>> iterator() {
     ensureOpen();
+
+    if (getConsistencyLevel() == ConsistencyLevel.IMMEDIATE) {
+      try {
+        String tableName = context.getTableName(tableId);
+        context.requireNotOffline(tableId, tableName);
+      } catch (TableNotFoundException e) {
+        throw new RuntimeException("Table not found", e);

Review Comment:
   I think we probably need a generic `UncheckedAccumuloException` so we can avoid the base RTE class and be able to easily distinguish from our RTEs and ones that libraries/user code might throw. `UncheckedIOException` is a good model to follow (though we don't always utilize that when we can; not currently, anyway).



##########
core/src/main/java/org/apache/accumulo/core/clientImpl/ThriftScanner.java:
##########
@@ -559,6 +580,11 @@ public Map<String,String> getHints() {
               "For tablet {} scan server selector chose scan_server:{} delay:{} busyTimeout:{}",
               loc.tablet_extent, scanServer, delay, scanState.busyTimeout);
         } else {
+          try {
+            context.requireNotOffline(scanState.tableId, context.getTableName(scanState.tableId));
+          } catch (TableNotFoundException e) {
+            throw new RuntimeException("Error scanning for table: " + scanState.tableId, e);

Review Comment:
   Some of these generic RTEs might be better expressed as IllegalStateException. In general, it's preferable to use a more specific RTE whenever possible.



-- 
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.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org