From 3543dd8baff9f2766d153d568b2bcc5a52156e39 Mon Sep 17 00:00:00 2001 From: Jonathan Shook Date: Fri, 26 Feb 2021 14:40:50 -0600 Subject: [PATCH] support counter error handler name for cross-compatibility --- .../activitytype/cql/api/ErrorResponse.java | 3 +- .../errorhandling/NBCycleErrorHandler.java | 1 + .../src/main/resources/cql-errors.md | 107 +++++++++--------- 3 files changed, 58 insertions(+), 53 deletions(-) diff --git a/driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/api/ErrorResponse.java b/driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/api/ErrorResponse.java index 74fd940d4..c6347282c 100644 --- a/driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/api/ErrorResponse.java +++ b/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; diff --git a/driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/errorhandling/NBCycleErrorHandler.java b/driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/errorhandling/NBCycleErrorHandler.java index 88ed8e17d..fc2549c9a 100644 --- a/driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/errorhandling/NBCycleErrorHandler.java +++ b/driver-cql-shaded/src/main/java/io/nosqlbench/activitytype/cql/errorhandling/NBCycleErrorHandler.java @@ -82,6 +82,7 @@ public class NBCycleErrorHandler implements CycleErrorHandlerretry # record histograms for WriteTimeoutException, error and stop # for everything else. - + errors=stop,WriteTimeoutException:histogram As you can see, the error handling format is pretty basic. Behind this basic @@ -32,10 +32,10 @@ Anytime you assign a value to the *errors* parameter for a cql activity, you are replacing the default 'stop,retryable->retry,unverified->stop' configuration. That is, each time this value is assigned, a new error handler is configured and installed according to the new value. - + ### errors= parameter format -The errors parameter contains a comma-separated list of one or more +The errors parameter contains a comma-separated list of one or more handler assignments where the error can be in any of these forms: - group name ( "unapplied" | "retryable" | "unverified" ) @@ -54,63 +54,66 @@ handler default for all non-specific errors in the form: # force the test to stop with any error, even retryable ones errors=stop - + ### Error Handler Verbs When an error occurs, you can control how it is handled for the most part. 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. -- **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. -- **count** - keep a count in metrics for the exception, under the name - errorcounts.classname, using the simple class name. + causing nosqlbench to shutdown the current scenario. +- **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. +- **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. - -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 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. + +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 -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. +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. 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,14 +125,14 @@ 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 The whole hierarchy of exceptions as of DSE Driver 3.2.0 is as follows, -with the default configuration shown. +with the default configuration shown. DriverException -> stop FrameTooLongException @@ -188,11 +191,11 @@ 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. 4. RetriesExhaustedException - Indicates that all retries were exhausted before a given operation could complete successfully. - +