support counter error handler name for cross-compatibility

driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/api/ErrorResponse.java

@@ -13,9 +13,10 @@ public enum ErrorResponse {
     retry("R"),     // resubmit this operation up to the available tries
     histogram("H"),     // record this metric in a histogram
     count("C"),     // count this metric separately
+    counter("C"),
     ignore("I");    // do nothing
 
-    private String symbol;
+    private final String symbol;
 
     ErrorResponse(String symbol) {
         this.symbol = symbol;

driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/errorhandling/NBCycleErrorHandler.java

@@ -82,6 +82,7 @@ public class NBCycleErrorHandler implements CycleErrorHandler<Throwable, ErrorSt
             case histogram:
                 exceptionHistoMetrics.update(error,cce.getDurationNanos());
             case count:
+            case counter:
                 exceptionCountMetrics.count(error);
             case ignore:
             default:

driver-cql-shaded/src/main/resources/cql-errors.md

@@ -62,55 +62,58 @@ This is the error handler stack:
 
 - **stop** - logs an error, and then rethrows the causing exception,
   causing nosqlbench to shutdown the current scenario.
-- **warn** - log a warning in the log, with details about the error 
-    and associated statement.
+- **warn** - log a warning in the log, with details about the error and
+  associated statement.
 - **retry** - Retry the operation if the number of retries hasn't been
   used up *and* the causing exception falls in the set of
   *retryable* errors.
-- **histogram** - keep a histogram of the exception counts, under the
-    name errorhistos.classname, using the simple class name.
-    The magnitude of these histos is how long the operation was pending
-    before the related error occurred.
+- **histogram** - keep a histogram of the exception counts, under the name
+  errorhistos.classname, using the simple class name. The magnitude of
+  these histos is how long the operation was pending before the related
+  error occurred.
 - **count** - keep a count in metrics for the exception, under the name
   errorcounts.classname, using the simple class name.
+- **counter** - same as **count**, added for compatibility with the newer
+  universal error handler. This one is the preferred name.
 - **ignore** - do nothing, do not even retry or count
 
 Each handling verb above is ordered from the most invasive to least
 invasive starting at the top. With the exception of the **stop**
-handler, the rest of them will be applied to an error all the way 
-to the bottom. For now, the error handling stack is exactly as above. 
-You can't modify it, although it may be made configurable in the future.
+handler, the rest of them will be applied to an error all the way to the
+bottom. For now, the error handling stack is exactly as above. You can't
+modify it, although it may be made configurable in the future.
 
-One way to choose the right handler is to say "How serious is this type
-of error to the test results if it happens?" In general, it is best 
-to be more conservative and choose a more aggressive setting unless you 
-are specifically wanting to measure how often a given error happens, 
-for example.
+One way to choose the right handler is to say "How serious is this type of
+error to the test results if it happens?" In general, it is best to be
+more conservative and choose a more aggressive setting unless you are
+specifically wanting to measure how often a given error happens, for
+example.
 
 Each exception type will have one and only one error handler at all times.
-No matter how you set an error handler for a class, only the most
-recently assigned handler stack will be active for it. This might be
-important to keep in mind when you make multiple assignments to potentially
-overlapping sets of error types. In any case, the default 'stop' handler
-will always catch an error that does not otherwise have a more specific
-handler assigned to it. 
+No matter how you set an error handler for a class, only the most recently
+assigned handler stack will be active for it. This might be important to
+keep in mind when you make multiple assignments to potentially overlapping
+sets of error types. In any case, the default 'stop' handler will always
+catch an error that does not otherwise have a more specific handler
+assigned to it.
 
 ##### Error Types
 
-The errors that can be handled are simply all the exception types that
-can be thrown by either the DataStax Java Driver for DSE, *or* the
-nosqlbench client itself. This includes errors that indicate a potentially
+The errors that can be handled are simply all the exception types that can
+be thrown by either the DataStax Java Driver for DSE, *or* the nosqlbench
+client itself. This includes errors that indicate a potentially
 intermittent failure condition. It also includes errors that are more
-permanent in nature, like WriteFailure, which would continue to occur
-on subsequent retries without some form of intervention. The nosqlbench 
+permanent in nature, like WriteFailure, which would continue to occur on
+subsequent retries without some form of intervention. The nosqlbench
 application will also generate some additional exceptions that capture
 common error cases that the Java driver doesn't or shouldn't have a
-special case for, but which may be important for nosqlbench testing purposes.
+special case for, but which may be important for nosqlbench testing
+purposes.
 
 In nosqlbench, all error handlers are specific to a particular kind of
 exception that you would catch in a typical application that uses DSE,
-although you can tell a handler to take care of a whole category
-of problems as long as you know the right name to use.
+although you can tell a handler to take care of a whole category of
+problems as long as you know the right name to use.
 
 ##### Assigned by Java Exception Type
 
@@ -122,9 +125,9 @@ by a closer parent or directly.
 ##### Assigning by Error Group Name
 
 Error types for which you would commonly assign the same handling behavior
-are also grouped in predefined names. If a handler is assigned to one
-of the group names, then the handler is assigned all of the exceptions
-in the group individually. For example, 'errors=retryable=stop' 
+are also grouped in predefined names. If a handler is assigned to one of
+the group names, then the handler is assigned all of the exceptions in the
+group individually. For example, 'errors=retryable=stop'
 
 ### Recognized Exceptions
 
@@ -188,8 +191,8 @@ handled alongside the normal exceptions as explained above.
 2. UnexpectedPaging - The UnexpectedPaging exception is meant to keep users from
    being surprised when there is paging activity in the workload, as this can have
    other implications for tuning and performance. See the details on the
-   **maxpages** parameter, and the *fetch size* parameter in the java driver for
-   details. 
+   **maxpages** parameter, and the *fetch size* parameter in the java
+   driver for details.
 3. Unverified\* Exceptions - For data set verification; These exceptions
    indicate when a cqlverify activity has found rows that differ from what
    was expected.