Merge branch 'master' into issue-67

.editorconfig

@@ -0,0 +1,19 @@
+# EditorConfig: http://EditorConfig.org
+
+root = true
+
+[*]
+end_of_line = lf
+insert_final_newline = true
+charset = utf-8
+indent_style = space
+trim_trailing_whitespace = true
+
+[pom.xml]
+indent_size = 4
+
+[*.java]
+indent_size = 4
+
+[*.{cmd,bat}]
+end_of_line = crlf

.github/workflows/build.yml

@@ -25,5 +25,8 @@ jobs:
         key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
         restore-keys: ${{ runner.os }}-m2   
 
-    - name: mvn package nosqlbench
+    - name: mvn package
       run: mvn package
+    
+    - name: mvn verify
+      run: mvn verify

.github/workflows/release.yml

@@ -12,7 +12,7 @@ jobs:
     - uses: actions/checkout@v2
     - uses: actions/setup-java@v1
       with:
-        java-version: '12'
+        java-version: '13'
         java-package: jdk
         architecture: x64
         
@@ -58,8 +58,10 @@ jobs:
         MINOR_VERSION=$(echo "$RELEASE_VERSION" | cut -d'.' -f3)
         NEXT_MINOR_VERSION=$(( MINOR_VERSION+1))
         NEXT_SNAPSHOT="${BASE_VERSION}.${NEXT_MINOR_VERSION}-SNAPSHOT"
+        RELEASE_TAGNAME="nosqlbench-${RELEASE_VERSION}"
         echo "::set-env name=NEXT_SNAPSHOT::${NEXT_SNAPSHOT}"
         echo "::set-env name=RELEASE_VERSION::${RELEASE_VERSION}"  
+        echo "::set-env name=RELEASE_TAGNAME::${RELEASE_TAGNAME}"
         
     - name: prepare release
       run: scripts/release-prepare.sh
@@ -114,6 +116,29 @@ jobs:
       with:
         name: guidebook
         path: guidebook
+    - name: find latest release
+      run: |
+        LATEST_GH_RELEASE_ID=$(curl --silent "https://api.github.com/repos/nosqlbench/nosqlbench/releases/latest" | jq -r .id)
+        echo "::set-env name=LATEST_GH_RELEASE_ID::${LATEST_GH_RELEASE_ID}"
+    - name: upload jar
+      uses: actions/upload-release-asset@v1
+      env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      with:
+          asset_path: nb/target/nb.jar
+          asset_name: nb.jar
+          asset_content_type: application/octet-stream
+          upload_url: https://uploads.github.com/repos/nosqlbench/nosqlbench/releases/${{ env.LATEST_GH_RELEASE_ID }}/assets?name=nb.jar
+    - name: upload binary
+      uses: actions/upload-release-asset@v1
+      env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      with: 
+          asset_path: nb/target/nb
+          asset_name: nb
+          asset_content_type: application/octet-stream
+          upload_url: https://uploads.github.com/repos/nosqlbench/nosqlbench/releases/${{ env.LATEST_GH_RELEASE_ID }}/assets?name=nb
+
   docs:
     needs: release
     runs-on: ubuntu-18.04

AUTOMATION.md

@@ -0,0 +1,19 @@
+## CI and Github Actions
+
+This project uses github actions to manage continuous integration.
+Below is a sketch of how the automation currently works.
+
+### releases
+
+The releases workflow is responsible for thie following:
+
+1. Build nb and nb.jar binaries and application content.
+2. Publish new nb.jar releases to maven via Sonatype OSSRH.
+3. Upload release assets to the newly published release.
+4. Upload updated docs to the github pages site for docs.nosqlbench.io
+5. (future) upload updated javadocs ot the github pages site for javadoc.nosqlbench.io/...
+
+### build
+
+The build workflow simply builds the project and then verifies it in that order
+using the standard maven mojo.

BUILDING.md

@@ -0,0 +1,31 @@
+# Building NoSQLBench
+
+## requirements
+
+You need Java 11 or newer to build NoSQLBench.
+
+# mvn package
+
+To build NoSQLBench in its entirety, you simply need to run
+
+`mvn package`
+
+The steps needed to build the full nb binary are all self-contained
+within the Maven build mojo, including the following:
+
+- Building all the maven modules
+- Building the nb binary in nb/target/nb using AppImage.
+- Building the guidebook app in docsys/src/main/resources/docsys-guidebook
+- Building the static guidebook in nb/target/guidebook
+- Exporting all the bundled markdown into nb/target/guidebook
+
+# mvn verify
+
+The integration tests for NoSQLBench are run in the verify phase.
+You can run these tests with `mvn verify`. These tests are based
+on invoking capsule-form scenario scripts and scrutinizing their
+output. They can take quite a bit of time, but there is no substitute
+for this level of testing, particularly for a tool that is used
+to test other systems.
+
+

MODULES.md

@@ -0,0 +1,43 @@
+## Contributing
+
+We are actively looking for contributors to help make NoSQLBench better.
+This is an ambitious project that is just finding its stride. If you want
+to be part of the next chapter in NoSQLBench development please look at
+[CONTRIBUTING](CONTRIBUTING.md) for ideas, and jump in where you feel comfortable.
+
+All contributors are expected to abide by the [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md).
+
+## License
+
+All of the code in this repository is licensed under the APL version 2. If you contribute
+to this project, then you must agree to license all of your construbutions under
+this license.
+
+# Project Structure
+
+NoSQLBench is an ambitious project. It has lots of advanced functionality
+built-in that you won't find in any other performance testing tool. That means that
+there is also a lot of code.
+
+To make a testing runtime that can be expanded according to different protocols and
+scripting requirements, modularity is absolutely essential. Thus, you will find many
+nodules, each focusing on one specific type of responsibility. The build system
+bundles all the modules together into a cohesive whole using SPI and auto-discovery
+mechanisms at run-time.
+
+To make it easier to find the module you are looking for, the following strict
+naming conventions have been adopted:
+
+- All packages within a module start with `io.nosqlbench`, followed by the module name,
+  with hyphens converted to dots. For example, the 'engine-api' module contains 
+  packages in `io.nosqlbench.engine.api`.
+- Modules which implement activity types (high-level protocol drivers) are named `activitytype-...`.
+- Modules which provide procedural data generation support are named `virtdata-...`.
+- Modules which provide core runtime logic are named `engine-...`.
+- Project-wide maven defaults are contained in the mvn-defaults module.
+
+All runtime packaging and bundling is done in the `nb` module. It produces a Linux binary
+  in target/eb. If you are doing testing and need to have a classpath that includes all th
+  bundled modules together, then use the `nb` module as your classpath module.
+
+

README.md

@@ -1,28 +1,71 @@
 ![build](https://github.com/nosqlbench/nosqlbench/workflows/build/badge.svg)
 
-This project combines upstream projects of engineblock and virtualdataset into one main project. More details on release practices and contributor guidelines are on the way.
+# NoSQLBench
 
-# Status
+**The Open Source, Pluggable, NoSQL Benchmarking Suite**
 
-This is in active development. Collaborators are welcome. However, there is still work to be done to groom the slope for new users.
+## What is NoSQLBench?
 
-# Project Structure
+NoSQLBench is a serious performance testing tool for the NoSQL ecosystem.
+It brings together features and capabilities that are not found in any
+other tool.
 
-NoSQLBench is a large project. It has lots of advanced functionality built-in that you won't find in any other performance testing tool.
+- You can run common testing workloads directly from the command line. You
+  can start doing this within 5 minutes of reading this.
+- You can generate virtual data sets of arbitrary size, with deterministic
+  data and statistically shaped values.
+- You can design custom workloads that emulate your application, contained
+  in a single file, based on statement templates - no IDE or coding required.
+- You can immediately plot your results in a docker and grafana stack on Linux
+  with a single command line option.
+- When needed, you can open the access panels and rewire the runtime behavior
+  of NoSQLBench to do advanced testing, including a full scripting environment
+  with Javascript.
 
-To make it easier to find the module you are looking for (for developers),
+The core machinery of NoSQLBench has been built with attention to detail.
-the following strict naming conventions have been adopted:
+It has been battle tested within DataStax as a way to help users validate their
+data models, baseline system performance, and qualify system designs for scale.
 
-- All original packages of this project start with `io.nosqlbench`.
+In short, NoSQLBench wishes to be a programmable power tool for performance
-- All original packages within each module are based directly on the above root package and the module name together. For example, the 'engine-api' module contains packages in `io.nosqlbench.engine.api`.
+testing. However, it is somewhat generic. It doesn't know directly about a
+particular type of system, or protocol. It simply provides a suitable machine
+harness in which to put your drivers and testing logic. If you know how to build
+a client for a particular kind of system, EB will let you load it like a plugin
+and control it dynamically.
 
-The procedural generation support that has been imported from the VirtualDataSet project now lives in virtdata-* modules.
+Initially, NoSQLBench comes with support for CQL, but we would like to see this
-The core runtime that used to be called EngineBlock now lives in engine-* modules.
+expanded with contributions from others.
 
-The binary packaging support for Linux (with AppImage) is contained in the nb module. It provides a binary `nb` which is the main command-line artifact from this project.
+## Origins
 
-The defaults that are used by all modules are contained in the mvn-defaults module.
+The code in this project comes from multiple sources. The procedural data
+generation capability was known before as 'Virtual Data Set'. The core runtime
+and scripting harness was from the 'EngineBlock' project. The CQL support was
+previously used within DataStax. In March of 2020, DataStax and the project
+maintainers for these projects decided to put everything into one OSS project
+in order to make contributions and sharing easier for everyone. Thus, the new
+project name and structure was launched as nosqlbench.io. NoSQLBench is an
+independent project that is sponsored by DataStax.
 
+We offer NoSQLBench as a new way of thinking about testing systems. It is not
+limited to testing only one type of system. It is our wish to build a community
+of users and practice around this project so that everyone in the NoSQL ecosystem
+can benefit from common concepts and understanding and reliable patterns of use.
+
+## Contributing
+
+We are actively looking for contributors to help make NoSQLBench better.
+This is an ambitious project that is just finding its stride. If you want
+to be part of the next chapter in NoSQLBench development please look at
+[CONTRIBUTING](CONTRIBUTING.md) for ideas, and jump in where you feel comfortable.
+
+All contributors are expected to abide by the [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md).
+
+## License
+
+All of the code in this repository is licensed under the APL version 2. If you contribute
+to this project, then you must agree to license all of your construbutions under
+this license.
 
 ## System Compatibility
 
@@ -32,46 +75,19 @@ This is a Linux targeted tool, as most cloud/nosql testing is done on Linux inst
 2. on Mac, with `nb.jar` all features are supported, except --docker-metrics
 3. On Windows, with `nb.jar` all features are supported, except --docker-metrics
 
-## nosqlbench
-
-This project aims to provide a missing power tool in the test tooling arsenal.
-
-The design goals:
-
-1. Provide a useful and intuitive Reusable Machine Pattern for constructing and reasoning about concurrent performance tests. To encourage this, the runtime machinery is based on [simple and tangible core concepts](http://docs.nosqlbench.io/user-guide/concepts/).
-2. Reduce testing time of complex scenarios with many variables. This is achieved by controlling tests from an [open javascript sandbox](http://docs.nosqlbench.io/user-guide/scripting/). This makes more sophisticated scenarios possible when needed.
-3. Minimize the amount of effort required to get empirical results from a test cycle. For this, [metrics reporting](http://docs.nosqlbench.io/user-guide/metrics/) is baked in.
-
-In short, NoSQLBench wishes to be a programmable power tool for performance
-testing. However, it is somewhat generic. It doesn't know directly about a
-particular type of system, or protocol. It simply provides a suitable machine
-harness in which to put your drivers and testing logic. If you know how to build
-a client for a particular kind of system, EB will let you load it like a plugin
-and control it dynamically.
-
-The most direct way to do this, if you are a tool developer, is to build your
-own activity type drivers and embed EB as the core runtime. You can always
-experiment with it and learn how it works by using the built-in diagnostic
-drivers.
-
-## History
-
-The NoSQLBench project started as a branch of [test
-client](http://github.com/jshook/testclient). It has since evolved to be more generic and capable.
-
-## License
-
-nosqlbench is licensed under the Apache Public License 2.0
-
 ## Thanks
 
 [![DataStax Logo](https://www.datastax.com/sites/default/files/content/graphics/logo/DS-logo-2019_1-25percent.png)](http://datastax.com/)
 
-This project is sponsored by [DataStax](http://datstax.com/) -- The always-on, active everywhere, distributed hybrid cloud database built on Apache Cassandra™, and designed from the ground up to run anywhere, on any cloud, in any datacenter, and in every possible combination. DataStax delivers the ultimate hybrid and multi-cloud database.
+This project is sponsored by [DataStax](http://datstax.com/) -- The always-on,
+active everywhere, distributed hybrid cloud database built on Apache Cassandra™,
+and designed from the ground up to run anywhere, on any cloud, in any datacenter,
+and in every possible combination. DataStax delivers the ultimate hybrid and multi-cloud database.
 
 ![YourKit Logo](https://www.yourkit.com/images/yklogo.png)
 
-This project uses tools provided by YourKit, LLC. YourKit supports open source projects with its full-featured Java Profiler.
+This project uses tools provided by YourKit, LLC. YourKit supports open source projects
-YourKit, LLC is the creator of <a href="https://www.yourkit.com/java/profiler/">YourKit Java Profiler</a>
+with its full-featured Java Profiler.  YourKit, LLC is the creator of
+<a href="https://www.yourkit.com/java/profiler/">YourKit Java Profiler</a>
 and <a href="https://www.yourkit.com/.net/profiler/">YourKit .NET Profiler</a>,
 innovative and intelligent tools for profiling Java and .NET applications.

_docs/services/docs/markdown/01_nosqlbench/04_support_options.md

@@ -1,22 +0,0 @@
----
-title: Support Options
-weight: 10
----
-
-# Support Options
-
-These guidelines are mirrored at the [Submitting Feedback](https://github.com/nosqlbench/nosqlbench/wiki/Submitting-Feedback) wiki page at the nosqlbench project site, which is also where the `[Submit Feedback]` link will take you.
-
-## Bug Fixes
-
-If you think you have found a bug, please [file a bug report](https://github.com/nosqlbench/nosqlbench/issues/new?labels=bug). nosqlbench is actively used within DataStax, and verified bugs will get attention as resources permit. Bugs reports which are more detailed, or bug reports which include steps to reproduce will get attention first.
-
-## Feature Requests
-
-If you would like to see something in nosqlbench that is not there yet,
-please [submit a feature request](https://github.com/nosqlbench/nosqlbench/issues/new?labels=feature).
-
-## Documentation Requests
-
-If you would like to see a specific nosqlbench or testing topic added to the guidebook, please [request docs content](https://github.com/nosqlbench/nosqlbench/issues/new?labels=docrequest).
-

_docs/services/docs/markdown/04_designing/index.md

@@ -1,31 +0,0 @@
----
-title: Designing Workloads
-weight: 40
----
-
-# Designing Workloads
-
-Workloads in nosqlbench are always controlled by a workload definition. Even the built-in workloads are simply pre-configured and controlled from a single YAML file which is bundled internally.
-
-With nosqlbench a standard YAML configuration format is provided that is used across all activity types. This makes it easy to specify statements, statement parameters, data bindings, and tags. This section describes the standard YAML format and how to use it.
-
-It is recommended that you read through the examples in each of the design sections in order. This guide was designed to give you a detailed understanding of workload construction with nosqlbench. The examples will also give you better insight into how nosqlbench works at a fundamental level.
-
-## Multi-Protocol Support
-
-You will notice that this guide is not overly CQL-specific. That is because nosqlbench is a multi-protocol tool. All that is needed for you to use this guide with other protocols is the release of more activity types. Try to keep that in mind as you think about designing workloads.
-
-## Advice for new builders
-
-### Review existing examples
-
-The built-in workloads that are include with nosqlbench are also shared on the github site where we manage the nosqlbench project:
-
-- [baselines](https://github.com/nosqlbench/nosqlbnech/tree/master/sample-activities/baselines)
-- [bindings](https://github.com/datastax/nosqlbench-labs/tree/master/sample-activities/bindings)
-
-### Follow the conventions
-
-The tagging conventions described under the YAML Conventions section will make your testing go smoother. All of the baselines that we publish for nosqlbench will use this form.
-
-

activitytype-cql/pom.xml

@@ -4,7 +4,7 @@
     <parent>
         <groupId>io.nosqlbench</groupId>
         <artifactId>mvn-defaults</artifactId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -28,7 +28,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>

activitytype-cql/src/main/java/io/nosqlbench/activitytype/cql/core/CqlActivity.java

@@ -10,7 +10,7 @@ import io.nosqlbench.activitytype.cql.api.ErrorResponse;
 import io.nosqlbench.activitytype.cql.api.ResultSetCycleOperator;
 import io.nosqlbench.activitytype.cql.api.RowCycleOperator;
 import io.nosqlbench.activitytype.cql.api.StatementFilter;
-import io.nosqlbench.activitytype.cql.errorhandling.EbdseCycleErrorHandler;
+import io.nosqlbench.activitytype.cql.errorhandling.NBCycleErrorHandler;
 import io.nosqlbench.activitytype.cql.errorhandling.HashedCQLErrorHandler;
 import io.nosqlbench.activitytype.cql.statements.binders.CqlBinderTypes;
 import io.nosqlbench.activitytype.cql.statements.core.*;
@@ -505,7 +505,7 @@ public class CqlActivity extends SimpleActivity implements Activity, ActivityDef
             if (keyval.length == 1) {
                 String verb = keyval[0];
                 newerrorHandler.setDefaultHandler(
-                        new EbdseCycleErrorHandler(
+                        new NBCycleErrorHandler(
                                 ErrorResponse.valueOf(verb),
                                 exceptionCountMetrics,
                                 exceptionHistoMetrics,
@@ -516,8 +516,8 @@ public class CqlActivity extends SimpleActivity implements Activity, ActivityDef
                 String pattern = keyval[0];
                 String verb = keyval[1];
                 if (newerrorHandler.getGroupNames().contains(pattern)) {
-                    EbdseCycleErrorHandler handler =
+                    NBCycleErrorHandler handler =
-                            new EbdseCycleErrorHandler(
+                            new NBCycleErrorHandler(
                                     ErrorResponse.valueOf(verb),
                                     exceptionCountMetrics,
                                     exceptionHistoMetrics,
@@ -526,7 +526,7 @@ public class CqlActivity extends SimpleActivity implements Activity, ActivityDef
                     logger.info("Handling error group '" + pattern + "' with handler:" + handler);
                     newerrorHandler.setHandlerForGroup(pattern, handler);
                 } else {
-                    EbdseCycleErrorHandler handler = new EbdseCycleErrorHandler(
+                    NBCycleErrorHandler handler = new NBCycleErrorHandler(
                             ErrorResponse.valueOf(keyval[1]),
                             exceptionCountMetrics,
                             exceptionHistoMetrics,

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

@@ -40,16 +40,16 @@ import org.slf4j.LoggerFactory;
  * simply a no-op that allows you to specify it as the minimum case.
  */
 @SuppressWarnings("Duplicates")
-public class EbdseCycleErrorHandler implements CycleErrorHandler<Throwable, ErrorStatus> {
+public class NBCycleErrorHandler implements CycleErrorHandler<Throwable, ErrorStatus> {
 
-    private static final Logger logger = LoggerFactory.getLogger(EbdseCycleErrorHandler.class);
+    private static final Logger logger = LoggerFactory.getLogger(NBCycleErrorHandler.class);
 
     private ErrorResponse errorResponse;
     private ExceptionCountMetrics exceptionCountMetrics;
     private final ExceptionHistoMetrics exceptionHistoMetrics;
     private boolean throwExceptionOnStop=false;
 
-    public EbdseCycleErrorHandler(
+    public NBCycleErrorHandler(
             ErrorResponse errorResponse,
             ExceptionCountMetrics exceptionCountMetrics,
             ExceptionHistoMetrics exceptionHistoMetrics,

activitytype-cql/src/main/java/io/nosqlbench/activitytype/cql/statements/core/CQLSessionCache.java

@@ -83,12 +83,12 @@ public class CQLSessionCache implements Shutdownable {
             contactPoints = activityDef.getParams().getOptionalString("hosts")
                     .map(h -> h.split(",")).orElse(null);
         }
+        if (contactPoints == null && scb.isEmpty()) {
+            contactPoints = new String[]{"localhost"};
+        }
 
         if (contactPoints != null) {
             builder.addContactPoints(contactPoints);
-        }else if (scb.isEmpty()){
-            throw new BasicError("you must provide your contact " +
-                    "points:\n    hosts=<host1,host2,...>");
         }
 
         activityDef.getParams().getOptionalInteger("port").ifPresent(builder::withPort);

activitytype-cql/src/main/resources/activities/baselines/cql-iot-dse.yaml

@@ -1,4 +1,4 @@
-# ebdse -v run type=cql yaml=baselines/cql-iot tags=phase:schema host=dsehost
+# nb -v run type=cql yaml=baselines/cql-iot tags=phase:schema host=dsehost
 bindings:
   machine_id: Mod(<<sources:10000>>); ToHashedUUID() -> java.util.UUID
   sensor_name: HashedLineToString('data/variable_words.txt')

activitytype-cql/src/main/resources/activities/baselines/cql-iot.yaml

@@ -1,5 +1,4 @@
-# nb -v run type=cql yaml=baselines/cql-iot tags=phase:schema
+# nb -v run type=cql yaml=baselines/cql-iot tags=phase:schema host=dsehost
-  host=dsehost
 bindings:
   machine_id: Mod(<<sources:10000>>); ToHashedUUID() -> java.util.UUID
   sensor_name: HashedLineToString('data/variable_words.txt')

activitytype-cql/src/main/resources/activities/baselines/cql-keyvalue.yaml

@@ -1,5 +1,4 @@
-# nb -v run type=cql yaml=baselines/cql-keyvalue tags=phase:schema
+# nb -v run type=cql yaml=baselines/cql-keyvalue tags=phase:schema host=dsehost
-  host=dsehost
 bindings:
   seq_key: Mod(<<keycount:1000000000>>); ToString() -> String
   seq_value: Hash(); Mod(<<valuecount:1000000000>>); ToString() -> String

activitytype-cql/src/main/resources/activities/baselines/cql-widerows.yaml

@@ -1,4 +1,4 @@
-# ebdse -v run type=cql yaml=baselines/cql-widerows tags=phase:schema host=dsehost
+# nb -v run type=cql yaml=baselines/cql-widerows tags=phase:schema host=dsehost
 bindings:
   # for ramp-up and verify
   part_layout: Div(<<partsize:1000000>>); ToString() -> String

activitytype-cqlverify/pom.xml

@@ -4,7 +4,7 @@
   <parent>
     <groupId>io.nosqlbench</groupId>
     <artifactId>mvn-defaults</artifactId>
-    <version>3.12.30-SNAPSHOT</version>
+    <version>3.12.42-SNAPSHOT</version>
     <relativePath>../mvn-defaults</relativePath>
   </parent>
 
@@ -24,7 +24,7 @@
     <dependency>
       <groupId>io.nosqlbench</groupId>
       <artifactId>activitytype-cql</artifactId>
-      <version>3.12.30-SNAPSHOT</version>
+      <version>3.12.42-SNAPSHOT</version>
     </dependency>
 
   </dependencies>

activitytype-diag/pom.xml

@@ -5,7 +5,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -20,7 +20,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>

activitytype-http/pom.xml

@@ -5,7 +5,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -21,7 +21,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <!-- test scope only -->

activitytype-stdout/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -21,7 +21,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <!-- test scope only -->

activitytype-tcp/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -23,13 +23,13 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>activitytype-stdout</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <!-- test scope only -->

docsys/pom.xml

@@ -9,7 +9,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -131,17 +131,17 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-processors</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-annotations</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
         <dependency>
             <groupId>org.slf4j</groupId>

docsys/src/main/node/docsys/nuxt.config.js

@@ -9,7 +9,7 @@ export default {
     ** Headers of the page
     */
     head: {
-        titleTemplate: '%s' + "nosqlbench docs",
+        titleTemplate: '%s' + "NoSQLBench Docs",
         title: process.env.npm_package_name || '',
         meta: [
             {charset: 'utf-8'},

docsys/src/main/node/docsys/pages/docs/_slug.vue

@@ -9,7 +9,7 @@
 
     <v-app-bar app dark color="secondary" collapse-on-scroll dense >
       <v-app-bar-nav-icon @click.stop="toggleDrawer"/>
-      <v-toolbar-title>nosqlbench docs</v-toolbar-title>
+      <v-toolbar-title>NoSQLBench Docs</v-toolbar-title>
       <v-spacer></v-spacer>
       <v-toolbar-items>
       </v-toolbar-items>

docsys/src/main/node/docsys/pages/docs/index.vue

@@ -8,10 +8,10 @@
 
     <v-app-bar app dark color="secondary">
       <v-app-bar-nav-icon color="primary" @click.stop="toggleDrawer"/>
-      <v-toolbar-title>nosqlbench docs</v-toolbar-title>
+      <v-toolbar-title>NoSQLBench Docs</v-toolbar-title>
       <v-spacer></v-spacer>
       <v-toolbar-items>
-        <v-btn text href="https://github.com/datastax/nosqlbench-labs/wiki/Submitting-Feedback">SUBMIT FEEDBACK</v-btn>
+        <v-btn text href="https://github.com/nosqlbench/nosqlbench/wiki/Submitting-Feedback">SUBMIT FEEDBACK</v-btn>
       </v-toolbar-items>
     </v-app-bar>
 

docsys/src/main/node/docsys/pages/index.vue

@@ -8,7 +8,7 @@
             <h2 class="subtitle">open source, pluggable, nosql benchmarking suite</h2>
             <div class="links">
                 <nuxt-link to="/docs/" class="button--purple">Documentation</nuxt-link>
-                <a href="https://community.datastax.com/spaces/51/index.html" class="button--purple">Community Site</a>
+                <a href="https://github.com/nosqlbench/nosqlbench" class="button--purple">Project Site</a>
             </div>
         </div>
     </div>

docsys/src/main/resources/docsys-guidebook/200.html

@@ -1,9 +1,9 @@
 <!doctype html>
 <html>
   <head>
-    <title>guidebooknosqlbench docs</title><meta data-n-head="1" charset="utf-8"><meta data-n-head="1" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="1" data-hid="description" name="description" content="Docs App for NoSQLBench"><link data-n-head="1" rel="icon" type="image/x-icon" href="/favicon.ico"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900&display=swap"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css"><link rel="preload" href="/_nuxt/71d233994867b9ff16c0.js" as="script"><link rel="preload" href="/_nuxt/ba3d87d913919f4a90b7.js" as="script"><link rel="preload" href="/_nuxt/b731eebc22dad37c5c4f.js" as="script"><link rel="preload" href="/_nuxt/4f2a13032e26b25bda78.js" as="script">
+    <title>guidebookNoSQLBench Docs</title><meta data-n-head="1" charset="utf-8"><meta data-n-head="1" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="1" data-hid="description" name="description" content="Docs App for NoSQLBench"><link data-n-head="1" rel="icon" type="image/x-icon" href="/favicon.ico"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900&display=swap"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css"><link rel="preload" href="/_nuxt/53667d09397c029ad15e.js" as="script"><link rel="preload" href="/_nuxt/ba3d87d913919f4a90b7.js" as="script"><link rel="preload" href="/_nuxt/b731eebc22dad37c5c4f.js" as="script"><link rel="preload" href="/_nuxt/7dd5646c91bbd00029e3.js" as="script">
   </head>
   <body>
     <div id="__nuxt"><style>#nuxt-loading{visibility:hidden;opacity:0;position:absolute;left:0;right:0;top:0;bottom:0;display:flex;justify-content:center;align-items:center;flex-direction:column;animation:nuxtLoadingIn 10s ease;-webkit-animation:nuxtLoadingIn 10s ease;animation-fill-mode:forwards;overflow:hidden}@keyframes nuxtLoadingIn{0%{visibility:hidden;opacity:0}20%{visibility:visible;opacity:0}100%{visibility:visible;opacity:1}}@-webkit-keyframes nuxtLoadingIn{0%{visibility:hidden;opacity:0}20%{visibility:visible;opacity:0}100%{visibility:visible;opacity:1}}#nuxt-loading>div,#nuxt-loading>div:after{border-radius:50%;width:5rem;height:5rem}#nuxt-loading>div{font-size:10px;position:relative;text-indent:-9999em;border:.5rem solid #f5f5f5;border-left:.5rem solid #fff;-webkit-transform:translateZ(0);-ms-transform:translateZ(0);transform:translateZ(0);-webkit-animation:nuxtLoading 1.1s infinite linear;animation:nuxtLoading 1.1s infinite linear}#nuxt-loading.error>div{border-left:.5rem solid #ff4500;animation-duration:5s}@-webkit-keyframes nuxtLoading{0%{-webkit-transform:rotate(0);transform:rotate(0)}100%{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}@keyframes nuxtLoading{0%{-webkit-transform:rotate(0);transform:rotate(0)}100%{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}</style><script>window.addEventListener("error",function(){var e=document.getElementById("nuxt-loading");e&&(e.className+=" error")})</script><div id="nuxt-loading" aria-live="polite" role="status"><div>Loading...</div></div></div>
-  <script type="text/javascript" src="/_nuxt/71d233994867b9ff16c0.js"></script><script type="text/javascript" src="/_nuxt/ba3d87d913919f4a90b7.js"></script><script type="text/javascript" src="/_nuxt/b731eebc22dad37c5c4f.js"></script><script type="text/javascript" src="/_nuxt/4f2a13032e26b25bda78.js"></script></body>
+  <script type="text/javascript" src="/_nuxt/53667d09397c029ad15e.js"></script><script type="text/javascript" src="/_nuxt/ba3d87d913919f4a90b7.js"></script><script type="text/javascript" src="/_nuxt/b731eebc22dad37c5c4f.js"></script><script type="text/javascript" src="/_nuxt/7dd5646c91bbd00029e3.js"></script></body>
 </html>

docsys/src/main/resources/docsys-guidebook/_nuxt/53667d09397c029ad15e.js

@@ -1 +1 @@
-!function(e){function r(data){for(var r,n,f=data[0],l=data[1],d=data[2],i=0,h=[];i<f.length;i++)n=f[i],Object.prototype.hasOwnProperty.call(o,n)&&o[n]&&h.push(o[n][0]),o[n]=0;for(r in l)Object.prototype.hasOwnProperty.call(l,r)&&(e[r]=l[r]);for(v&&v(data);h.length;)h.shift()();return c.push.apply(c,d||[]),t()}function t(){for(var e,i=0;i<c.length;i++){for(var r=c[i],t=!0,n=1;n<r.length;n++){var l=r[n];0!==o[l]&&(t=!1)}t&&(c.splice(i--,1),e=f(f.s=r[0]))}return e}var n={},o={8:0},c=[];function f(r){if(n[r])return n[r].exports;var t=n[r]={i:r,l:!1,exports:{}};return e[r].call(t.exports,t,t.exports,f),t.l=!0,t.exports}f.e=function(e){var r=[],t=o[e];if(0!==t)if(t)r.push(t[2]);else{var n=new Promise((function(r,n){t=o[e]=[r,n]}));r.push(t[2]=n);var c,script=document.createElement("script");script.charset="utf-8",script.timeout=120,f.nc&&script.setAttribute("nonce",f.nc),script.src=function(e){return f.p+""+{0:"55bb9a1be83797eee63f",1:"b8a47e05eded23bac7ed",4:"c28caf599093f6fe5786",5:"09eb2af0af9c15c6d621",6:"428c6c33fdbc344a773a",7:"59759ea4aa8651f70220"}[e]+".js"}(e);var l=new Error;c=function(r){script.onerror=script.onload=null,clearTimeout(d);var t=o[e];if(0!==t){if(t){var n=r&&("load"===r.type?"missing":r.type),c=r&&r.target&&r.target.src;l.message="Loading chunk "+e+" failed.\n("+n+": "+c+")",l.name="ChunkLoadError",l.type=n,l.request=c,t[1](l)}o[e]=void 0}};var d=setTimeout((function(){c({type:"timeout",target:script})}),12e4);script.onerror=script.onload=c,document.head.appendChild(script)}return Promise.all(r)},f.m=e,f.c=n,f.d=function(e,r,t){f.o(e,r)||Object.defineProperty(e,r,{enumerable:!0,get:t})},f.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},f.t=function(e,r){if(1&r&&(e=f(e)),8&r)return e;if(4&r&&"object"==typeof e&&e&&e.__esModule)return e;var t=Object.create(null);if(f.r(t),Object.defineProperty(t,"default",{enumerable:!0,value:e}),2&r&&"string"!=typeof e)for(var n in e)f.d(t,n,function(r){return e[r]}.bind(null,n));return t},f.n=function(e){var r=e&&e.__esModule?function(){return e.default}:function(){return e};return f.d(r,"a",r),r},f.o=function(object,e){return Object.prototype.hasOwnProperty.call(object,e)},f.p="/_nuxt/",f.oe=function(e){throw console.error(e),e};var l=window.webpackJsonp=window.webpackJsonp||[],d=l.push.bind(l);l.push=r,l=l.slice();for(var i=0;i<l.length;i++)r(l[i]);var v=d;t()}([]);
+!function(e){function r(data){for(var r,n,f=data[0],l=data[1],d=data[2],i=0,h=[];i<f.length;i++)n=f[i],Object.prototype.hasOwnProperty.call(o,n)&&o[n]&&h.push(o[n][0]),o[n]=0;for(r in l)Object.prototype.hasOwnProperty.call(l,r)&&(e[r]=l[r]);for(v&&v(data);h.length;)h.shift()();return c.push.apply(c,d||[]),t()}function t(){for(var e,i=0;i<c.length;i++){for(var r=c[i],t=!0,n=1;n<r.length;n++){var l=r[n];0!==o[l]&&(t=!1)}t&&(c.splice(i--,1),e=f(f.s=r[0]))}return e}var n={},o={8:0},c=[];function f(r){if(n[r])return n[r].exports;var t=n[r]={i:r,l:!1,exports:{}};return e[r].call(t.exports,t,t.exports,f),t.l=!0,t.exports}f.e=function(e){var r=[],t=o[e];if(0!==t)if(t)r.push(t[2]);else{var n=new Promise((function(r,n){t=o[e]=[r,n]}));r.push(t[2]=n);var c,script=document.createElement("script");script.charset="utf-8",script.timeout=120,f.nc&&script.setAttribute("nonce",f.nc),script.src=function(e){return f.p+""+{0:"55bb9a1be83797eee63f",1:"b8a47e05eded23bac7ed",4:"b3e025f0863187be1b03",5:"d367b2f4f2ccc5cdcc57",6:"428c6c33fdbc344a773a",7:"ecd4a42f2cc80fb75abd"}[e]+".js"}(e);var l=new Error;c=function(r){script.onerror=script.onload=null,clearTimeout(d);var t=o[e];if(0!==t){if(t){var n=r&&("load"===r.type?"missing":r.type),c=r&&r.target&&r.target.src;l.message="Loading chunk "+e+" failed.\n("+n+": "+c+")",l.name="ChunkLoadError",l.type=n,l.request=c,t[1](l)}o[e]=void 0}};var d=setTimeout((function(){c({type:"timeout",target:script})}),12e4);script.onerror=script.onload=c,document.head.appendChild(script)}return Promise.all(r)},f.m=e,f.c=n,f.d=function(e,r,t){f.o(e,r)||Object.defineProperty(e,r,{enumerable:!0,get:t})},f.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},f.t=function(e,r){if(1&r&&(e=f(e)),8&r)return e;if(4&r&&"object"==typeof e&&e&&e.__esModule)return e;var t=Object.create(null);if(f.r(t),Object.defineProperty(t,"default",{enumerable:!0,value:e}),2&r&&"string"!=typeof e)for(var n in e)f.d(t,n,function(r){return e[r]}.bind(null,n));return t},f.n=function(e){var r=e&&e.__esModule?function(){return e.default}:function(){return e};return f.d(r,"a",r),r},f.o=function(object,e){return Object.prototype.hasOwnProperty.call(object,e)},f.p="/_nuxt/",f.oe=function(e){throw console.error(e),e};var l=window.webpackJsonp=window.webpackJsonp||[],d=l.push.bind(l);l.push=r,l=l.slice();for(var i=0;i<l.length;i++)r(l[i]);var v=d;t()}([]);

docsys/src/main/resources/docsys-guidebook/index.html

@@ -1,9 +1,9 @@
 <!doctype html>
 <html>
   <head>
-    <title>guidebooknosqlbench docs</title><meta data-n-head="1" charset="utf-8"><meta data-n-head="1" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="1" data-hid="description" name="description" content="Docs App for NoSQLBench"><link data-n-head="1" rel="icon" type="image/x-icon" href="/favicon.ico"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900&display=swap"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css"><link rel="preload" href="/_nuxt/71d233994867b9ff16c0.js" as="script"><link rel="preload" href="/_nuxt/ba3d87d913919f4a90b7.js" as="script"><link rel="preload" href="/_nuxt/b731eebc22dad37c5c4f.js" as="script"><link rel="preload" href="/_nuxt/4f2a13032e26b25bda78.js" as="script">
+    <title>guidebookNoSQLBench Docs</title><meta data-n-head="1" charset="utf-8"><meta data-n-head="1" name="viewport" content="width=device-width,initial-scale=1"><meta data-n-head="1" data-hid="description" name="description" content="Docs App for NoSQLBench"><link data-n-head="1" rel="icon" type="image/x-icon" href="/favicon.ico"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900&display=swap"><link data-n-head="1" rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/@mdi/font@latest/css/materialdesignicons.min.css"><link rel="preload" href="/_nuxt/53667d09397c029ad15e.js" as="script"><link rel="preload" href="/_nuxt/ba3d87d913919f4a90b7.js" as="script"><link rel="preload" href="/_nuxt/b731eebc22dad37c5c4f.js" as="script"><link rel="preload" href="/_nuxt/7dd5646c91bbd00029e3.js" as="script">
   </head>
   <body>
     <div id="__nuxt"><style>#nuxt-loading{visibility:hidden;opacity:0;position:absolute;left:0;right:0;top:0;bottom:0;display:flex;justify-content:center;align-items:center;flex-direction:column;animation:nuxtLoadingIn 10s ease;-webkit-animation:nuxtLoadingIn 10s ease;animation-fill-mode:forwards;overflow:hidden}@keyframes nuxtLoadingIn{0%{visibility:hidden;opacity:0}20%{visibility:visible;opacity:0}100%{visibility:visible;opacity:1}}@-webkit-keyframes nuxtLoadingIn{0%{visibility:hidden;opacity:0}20%{visibility:visible;opacity:0}100%{visibility:visible;opacity:1}}#nuxt-loading>div,#nuxt-loading>div:after{border-radius:50%;width:5rem;height:5rem}#nuxt-loading>div{font-size:10px;position:relative;text-indent:-9999em;border:.5rem solid #f5f5f5;border-left:.5rem solid #fff;-webkit-transform:translateZ(0);-ms-transform:translateZ(0);transform:translateZ(0);-webkit-animation:nuxtLoading 1.1s infinite linear;animation:nuxtLoading 1.1s infinite linear}#nuxt-loading.error>div{border-left:.5rem solid #ff4500;animation-duration:5s}@-webkit-keyframes nuxtLoading{0%{-webkit-transform:rotate(0);transform:rotate(0)}100%{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}@keyframes nuxtLoading{0%{-webkit-transform:rotate(0);transform:rotate(0)}100%{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}</style><script>window.addEventListener("error",function(){var e=document.getElementById("nuxt-loading");e&&(e.className+=" error")})</script><div id="nuxt-loading" aria-live="polite" role="status"><div>Loading...</div></div></div>
-  <script type="text/javascript" src="/_nuxt/71d233994867b9ff16c0.js"></script><script type="text/javascript" src="/_nuxt/ba3d87d913919f4a90b7.js"></script><script type="text/javascript" src="/_nuxt/b731eebc22dad37c5c4f.js"></script><script type="text/javascript" src="/_nuxt/4f2a13032e26b25bda78.js"></script></body>
+  <script type="text/javascript" src="/_nuxt/53667d09397c029ad15e.js"></script><script type="text/javascript" src="/_nuxt/ba3d87d913919f4a90b7.js"></script><script type="text/javascript" src="/_nuxt/b731eebc22dad37c5c4f.js"></script><script type="text/javascript" src="/_nuxt/7dd5646c91bbd00029e3.js"></script></body>
 </html>

engine-api/pom.xml

@@ -5,7 +5,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -22,7 +22,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-userlibs</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
@@ -112,6 +112,11 @@
             <version>4.1.45.Final</version>
         </dependency>
 
+        <dependency>
+          <groupId>com.github.oshi</groupId>
+          <artifactId>oshi-core</artifactId>
+        </dependency>
+
         <dependency>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-shade-plugin</artifactId>

engine-api/src/main/java/io/nosqlbench/engine/api/activityimpl/CpuInfo.java

@@ -17,8 +17,11 @@
 
 package io.nosqlbench.engine.api.activityimpl;
 
+import oshi.SystemInfo;
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
+import oshi.hardware.CentralProcessor;
+import oshi.hardware.HardwareAbstractionLayer;
 
 import java.nio.charset.StandardCharsets;
 import java.nio.file.Files;
@@ -28,88 +31,54 @@ import java.util.*;
 public class CpuInfo {
     private final static Logger logger = LoggerFactory.getLogger(CpuInfo.class);
 
-    public static Optional<ProcDetails> getProcDetails() {
+    final private static SystemInfo SYSTEM_INFO = new SystemInfo();
-        List<Map<String, String>> cpuinfo = new ArrayList<>();
-        try {
-            String data = Files.readString(Path.of("/proc/cpuinfo"), StandardCharsets.UTF_8);
-            String[] sections = data.split("\n\n");
-            for (String section : sections) {
-                Map<String, String> cpuMap = new HashMap<>();
-                cpuinfo.add(cpuMap);
 
-                String[] props = section.split("\n");
+    public static Optional<ProcDetails> getProcDetails() {
-                for (String prop : props) {
+        return Optional.of(new ProcDetails(SYSTEM_INFO));
-                    String[] assignment = prop.split("\\s*:\\s*");
-                    if (assignment.length == 2) {
-                        String property = assignment[0].trim();
-                        String value = assignment[1].trim();
-                        cpuMap.put(property, value);
-                    } else {
-                        cpuMap.put(assignment[0], "");
-                    }
-                }
-            }
-        } catch (Exception e) {
-            logger.warn("Unable to learn about CPU architecture: " + e.getMessage());
-            return Optional.empty();
-        }
-        return Optional.of(new ProcDetails(cpuinfo));
     }
 
-
     public static class ProcDetails {
-        private final List<Map<String, String>> details;
+        SystemInfo si;
+        HardwareAbstractionLayer hal;
+        CentralProcessor processor;
 
-        public ProcDetails(List<Map<String, String>> details) {
+        public ProcDetails(SystemInfo si) {
-            this.details = details;
+            this.si = si;
+            this.hal = si.getHardware();
+            this.processor = hal.getProcessor();
         }
 
         public int getCoreCount() {
-            return (int) details.stream()
+            return processor.getLogicalProcessorCount();
-                    .map(m -> m.get("core id"))
-                    .distinct()
-                    .count();
         }
 
         public int getCpuCount() {
-            return (int) details.stream()
+            return processor.getPhysicalProcessorCount();
-                    .map(m -> m.get("processor"))
-                    .distinct()
-                    .count();
         }
 
         public String getModelName() {
-            return details.stream()
+            return processor.getProcessorIdentifier().toString();
-                    .map(m -> m.get("model name")).findFirst().orElseThrow();
         }
 
         public String getMhz() {
-            return details.stream()
+            // or use processor.getCurrentFreq, and average, or min?
-                    .map(m -> m.get("cpu MHz")).findFirst().orElseThrow();
+            return Long.toString(processor.getMaxFreq()/ (1024*1024));
-        }
-
-        public String getCacheInfo() {
-            return details.stream()
-                    .map(m -> m.get("cache size")).findFirst().orElseThrow();
         }
 
         public String toString() {
             return "cores=" + getCoreCount() +
                     " cpus=" + getCpuCount() + " mhz=" + getMhz() +
                     " speedavg=" + getCurrentSpeed().getAverage() +
-                    " cache=" + getCacheInfo() + " model='" + getModelName() + "'";
+                    " model='" + getModelName() + "'";
 
         }
 
 
         public double getMaxFreq(int cpu) {
-            return readFile("/sys/devices/system/cpu/cpu" + cpu + "/cpufreq/cpuinfo_max_freq",Double.NaN);
+            return (double)processor.getMaxFreq();
         }
         public double getCurFreq(int cpu) {
-            return readFile("/sys/devices/system/cpu/cpu" + cpu + "/cpufreq/cpuinfo_max_freq",Double.NaN);
+            return (double)processor.getCurrentFreq()[cpu];
-        }
-        public double getMinFreq(int cpu) {
-            return readFile("/sys/devices/system/cpu/cpu" + cpu + "/cpufreq/cpuinfo_min_freq",Double.NaN);
         }
 
         public double getCurrentSpeed(int cpu) {
@@ -132,14 +101,5 @@ public class CpuInfo {
             return dss;
         }
 
-        private double readFile(String path, double defaultValue) {
-            try {
-                Path readPath = Path.of(path);
-                String content = Files.readString(readPath);
-                return Double.parseDouble(content);
-            } catch (Exception e) {
-                return defaultValue;
-            }
-        }
     }
 }

engine-api/src/test/java/io/nosqlbench/engine/api/activityimpl/CpuInfoTest.java

@@ -17,7 +17,7 @@
 
 package io.nosqlbench.engine.api.activityimpl;
 
-import org.junit.Test;
+import org.testng.annotations.Test;
 
 import java.util.Optional;
 

engine-cli/pom.xml

@@ -4,7 +4,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -23,13 +23,13 @@
     <dependency>
       <groupId>io.nosqlbench</groupId>
       <artifactId>engine-core</artifactId>
-      <version>3.12.30-SNAPSHOT</version>
+      <version>3.12.42-SNAPSHOT</version>
     </dependency>
 
     <dependency>
       <groupId>io.nosqlbench</groupId>
       <artifactId>engine-docker</artifactId>
-      <version>3.12.30-SNAPSHOT</version>
+      <version>3.12.42-SNAPSHOT</version>
       <classifier>shaded</classifier>
     </dependency>
 
@@ -61,7 +61,7 @@
     <dependency>
       <groupId>io.nosqlbench</groupId>
       <artifactId>engine-docker</artifactId>
-      <version>3.12.30-SNAPSHOT</version>
+      <version>3.12.42-SNAPSHOT</version>
     </dependency>
 
 

engine-cli/src/main/java/io/nosqlbench/engine/cli/NBCLI.java

@@ -53,7 +53,7 @@ public class NBCLI {
             System.exit(0);
         }
 
-        EBCLIOptions options = new EBCLIOptions(args);
+        NBCLIOptions options = new NBCLIOptions(args);
 
         if (options.wantsBasicHelp()) {
             System.out.println(loadHelpFile("commandline.md"));
@@ -161,13 +161,13 @@ public class NBCLI {
             }
         }
 
-        for (EBCLIOptions.LoggerConfig histoLogger : options.getHistoLoggerConfigs()) {
+        for (NBCLIOptions.LoggerConfig histoLogger : options.getHistoLoggerConfigs()) {
             ActivityMetrics.addHistoLogger(sessionName, histoLogger.pattern, histoLogger.file, histoLogger.interval);
         }
-        for (EBCLIOptions.LoggerConfig statsLogger : options.getStatsLoggerConfigs()) {
+        for (NBCLIOptions.LoggerConfig statsLogger : options.getStatsLoggerConfigs()) {
             ActivityMetrics.addStatsLogger(sessionName, statsLogger.pattern, statsLogger.file, statsLogger.interval);
         }
-        for (EBCLIOptions.LoggerConfig classicConfigs : options.getClassicHistoConfigs()) {
+        for (NBCLIOptions.LoggerConfig classicConfigs : options.getClassicHistoConfigs()) {
             ActivityMetrics.addClassicHistos(sessionName, classicConfigs.pattern, classicConfigs.file, classicConfigs.interval);
         }
 
@@ -183,7 +183,7 @@ public class NBCLI {
         ScenariosExecutor executor = new ScenariosExecutor("executor-" + sessionName, 1);
 
         Scenario scenario = new Scenario(sessionName, options.getProgressSpec());
-        EBCLIScriptAssembly.ScriptData scriptData = EBCLIScriptAssembly.assembleScript(options);
+        NBCLIScriptAssembly.ScriptData scriptData = NBCLIScriptAssembly.assembleScript(options);
         if (options.wantsShowScript()) {
             System.out.println("// Rendered Script");
             System.out.println(scriptData.getScriptParamsAndText());

engine-cli/src/main/java/io/nosqlbench/engine/cli/NBCLIOptions.java

@@ -17,10 +17,10 @@ import java.util.stream.Collectors;
  * No CLI parser lib is useful for command structures, it seems. So we have this instead, which is good enough.
  * If something better is needed later, this can be replaced.
  */
-public class EBCLIOptions {
+public class NBCLIOptions {
 
     public static final String docoptFileName = "commandline.md";
-    private final static Logger logger = LoggerFactory.getLogger(EBCLIOptions.class);
+    private final static Logger logger = LoggerFactory.getLogger(NBCLIOptions.class);
 
     // Discovery
     private static final String HELP = "--help";
@@ -109,7 +109,7 @@ public class EBCLIOptions {
     private boolean enableChart = false;
     private boolean dockerMetrics = false;
 
-    public EBCLIOptions(String[] args) {
+    public NBCLIOptions(String[] args) {
         parse(args);
     }
 

engine-cli/src/main/java/io/nosqlbench/engine/cli/NBCLIScriptAssembly.java

@@ -11,15 +11,15 @@ import java.util.HashMap;
 import java.util.Map;
 import java.util.stream.Collectors;
 
-public class EBCLIScriptAssembly {
+public class NBCLIScriptAssembly {
-    private final static Logger logger = LoggerFactory.getLogger(EBCLIScriptAssembly.class);
+    private final static Logger logger = LoggerFactory.getLogger(NBCLIScriptAssembly.class);
 
-    public static ScriptData assembleScript(EBCLIOptions options) {
+    public static ScriptData assembleScript(NBCLIOptions options) {
         StringBuilder sb = new StringBuilder();
         Map<String,String> params = new HashMap<>();
-        for (EBCLIOptions.Cmd cmd : options.getCommands()) {
+        for (NBCLIOptions.Cmd cmd : options.getCommands()) {
             String cmdSpec = cmd.getCmdSpec();
-            EBCLIOptions.CmdType cmdType = cmd.getCmdType();
+            NBCLIOptions.CmdType cmdType = cmd.getCmdType();
             ActivityDef activityDef;
             switch (cmd.getCmdType()) {
                 case script:
@@ -71,7 +71,7 @@ public class EBCLIScriptAssembly {
         return new ScriptData(sb.toString(), params);
     }
 
-    private static ScriptData loadScript(EBCLIOptions.Cmd cmd) {
+    private static ScriptData loadScript(NBCLIOptions.Cmd cmd) {
         String scriptData;
 
         try {

engine-cli/src/test/java/io/nosqlbench/engine/cli/NBCLIScriptAssemblyTest.java

@@ -18,7 +18,8 @@
 package io.nosqlbench.engine.cli;
 
 
-
+import io.nosqlbench.engine.cli.NBCLIOptions;
+import io.nosqlbench.engine.cli.NBCLIScriptAssembly;
 import org.testng.annotations.Test;
 
 import static org.assertj.core.api.Assertions.assertThat;
@@ -27,19 +28,19 @@ public class NBCLIScriptAssemblyTest {
 
     @Test
     public void testScriptParamsSingle() {
-        EBCLIOptions opts = new EBCLIOptions(new String[] {
+        NBCLIOptions opts = new NBCLIOptions(new String[] {
                 "script",
                 "testscripts/printscript.js",
                 "param1=value1"
         });
-        EBCLIScriptAssembly.ScriptData sd = EBCLIScriptAssembly.assembleScript(opts);
+        NBCLIScriptAssembly.ScriptData sd = NBCLIScriptAssembly.assembleScript(opts);
         String assembledScript = sd.getScriptTextIgnoringParams();
         assertThat(assembledScript).matches("(?s).*a single line.*");
     }
 
     @Test
     public void testScriptParamsMulti() {
-        EBCLIOptions opts = new EBCLIOptions(new String[] {
+        NBCLIOptions opts = new NBCLIOptions(new String[] {
                 "script",
                 "testscripts/printscript.js",
                 "param1=value1",
@@ -48,7 +49,7 @@ public class NBCLIScriptAssemblyTest {
                 "paramname=another",
                 "param2=andanother"
         });
-        EBCLIScriptAssembly.ScriptData sd = EBCLIScriptAssembly.assembleScript(opts);
+        NBCLIScriptAssembly.ScriptData sd = NBCLIScriptAssembly.assembleScript(opts);
         String assembledScript = sd.getScriptTextIgnoringParams();
         assertThat(assembledScript).matches("(?s).*a single line.*");
     }

engine-cli/src/test/java/io/nosqlbench/engine/cli/TestNBCLIOptions.java

@@ -12,7 +12,7 @@ public class TestNBCLIOptions {
 
     @Test
     public void shouldRecognizeActivities() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"start", "foo=wan", "start", "bar=lan"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"start", "foo=wan", "start", "bar=lan"});
         assertThat(opts.getCommands()).isNotNull();
         assertThat(opts.getCommands().size()).isEqualTo(2);
         assertThat(opts.getCommands().get(0).getCmdSpec()).isEqualTo("foo=wan;");
@@ -21,7 +21,7 @@ public class TestNBCLIOptions {
 
     @Test
     public void shouldParseLongActivityForm() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"start", "param1=param2", "param3=param4",
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"start", "param1=param2", "param3=param4",
                                                           "--report-graphite-to", "woot", "--report-interval", "23"});
         assertThat(opts.getCommands().size()).isEqualTo(1);
         assertThat(opts.getCommands().get(0).getCmdSpec()).isEqualTo("param1=param2;param3=param4;");
@@ -31,64 +31,64 @@ public class TestNBCLIOptions {
 
     @Test
     public void shouldRecognizeShortVersion() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"--version"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"--version"});
         assertThat(opts.isWantsVersionShort()).isTrue();
         assertThat(opts.wantsVersionCoords()).isFalse();
     }
 
     @Test
     public void shouldRecognizeVersion() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"--version-coords"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"--version-coords"});
         assertThat(opts.isWantsVersionShort()).isFalse();
         assertThat(opts.wantsVersionCoords()).isTrue();
     }
 
     @Test
     public void shouldRecognizeScripts() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"script", "ascriptaone", "script", "ascriptatwo"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"script", "ascriptaone", "script", "ascriptatwo"});
         assertThat(opts.getCommands()).isNotNull();
         assertThat(opts.getCommands().size()).isEqualTo(2);
-        assertThat(opts.getCommands().get(0).getCmdType()).isEqualTo(EBCLIOptions.CmdType.script);
+        assertThat(opts.getCommands().get(0).getCmdType()).isEqualTo(NBCLIOptions.CmdType.script);
         assertThat(opts.getCommands().get(0).getCmdSpec()).isEqualTo("ascriptaone");
-        assertThat(opts.getCommands().get(1).getCmdType()).isEqualTo(EBCLIOptions.CmdType.script);
+        assertThat(opts.getCommands().get(1).getCmdType()).isEqualTo(NBCLIOptions.CmdType.script);
         assertThat(opts.getCommands().get(1).getCmdSpec()).isEqualTo("ascriptatwo");
     }
 
     @Test
     public void shouldRecognizeWantsActivityTypes() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"--list-activity-types"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"--list-activity-types"});
         assertThat(opts.wantsActivityTypes()).isTrue();
-        opts = new EBCLIOptions(new String[]{"--version"});
+        opts = new NBCLIOptions(new String[]{"--version"});
         assertThat(opts.wantsActivityTypes()).isFalse();
     }
 
     @Test
     public void shouldRecognizeWantsBasicHelp() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"--help"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"--help"});
         assertThat(opts.wantsBasicHelp()).isTrue();
-        opts = new EBCLIOptions(new String[]{"--version"});
+        opts = new NBCLIOptions(new String[]{"--version"});
         assertThat(opts.wantsTopicalHelp()).isFalse();
     }
 
     @Test
     public void shouldRecognizeWantsActivityHelp() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"--help", "foo"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"--help", "foo"});
         assertThat(opts.wantsTopicalHelp()).isTrue();
         assertThat(opts.wantsTopicalHelpFor()).isEqualTo("foo");
-        opts = new EBCLIOptions(new String[]{"--version"});
+        opts = new NBCLIOptions(new String[]{"--version"});
         assertThat(opts.wantsTopicalHelp()).isFalse();
     }
 
     @Test(expectedExceptions = {InvalidParameterException.class}, expectedExceptionsMessageRegExp = ".*unrecognized option.*")
     public void shouldErrorSanelyWhenNoMatch() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"unrecognizable command"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"unrecognizable command"});
     }
 
     @Test
     public void testShouldRecognizeScriptParams() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"script", "ascript", "param1=value1"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"script", "ascript", "param1=value1"});
         assertThat(opts.getCommands().size()).isEqualTo(1);
-        EBCLIOptions.Cmd cmd = opts.getCommands().get(0);
+        NBCLIOptions.Cmd cmd = opts.getCommands().get(0);
         assertThat(cmd.getCmdArgs().size()).isEqualTo(1);
         assertThat(cmd.getCmdArgs()).containsKey("param1");
         assertThat(cmd.getCmdArgs().get("param1")).isEqualTo("value1");
@@ -97,93 +97,93 @@ public class TestNBCLIOptions {
     @Test(expectedExceptions = {InvalidParameterException.class},
             expectedExceptionsMessageRegExp = ".*script name must precede.*")
     public void testShouldErrorSanelyWhenScriptNameSkipped() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"script", "param1=value1"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"script", "param1=value1"});
     }
 
     @Test(expectedExceptions = {InvalidParameterException.class},
     expectedExceptionsMessageRegExp = ".*script name not found.*")
     public void testShouldErrorForMissingScriptName() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"script"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"script"});
     }
 
     @Test
     public void testScriptInterpolation() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{"script", "script_to_interpolate", "parameter1=replaced"});
+        NBCLIOptions opts = new NBCLIOptions(new String[]{"script", "script_to_interpolate", "parameter1=replaced"});
-        EBCLIScriptAssembly.ScriptData s = EBCLIScriptAssembly.assembleScript(opts);
+        NBCLIScriptAssembly.ScriptData s = NBCLIScriptAssembly.assembleScript(opts);
         assertThat(s.getScriptTextIgnoringParams()).contains("var foo=replaced;");
         assertThat(s.getScriptTextIgnoringParams()).contains("var bar=UNSET:parameter2");
     }
 
     @Test
     public void testAutoScriptCommand() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{ "acommand" });
+        NBCLIOptions opts = new NBCLIOptions(new String[]{ "acommand" });
-        EBCLIScriptAssembly.ScriptData s = EBCLIScriptAssembly.assembleScript(opts);
+        NBCLIScriptAssembly.ScriptData s = NBCLIScriptAssembly.assembleScript(opts);
         assertThat(s.getScriptTextIgnoringParams()).contains("acommand script text");
     }
 
     @Test
     public void shouldRecognizeStartActivityCmd() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{ "start", "type=woot" });
+        NBCLIOptions opts = new NBCLIOptions(new String[]{ "start", "type=woot" });
-        List<EBCLIOptions.Cmd> cmds = opts.getCommands();
+        List<NBCLIOptions.Cmd> cmds = opts.getCommands();
         assertThat(cmds).hasSize(1);
-        assertThat(cmds.get(0).getCmdType()).isEqualTo(EBCLIOptions.CmdType.start);
+        assertThat(cmds.get(0).getCmdType()).isEqualTo(NBCLIOptions.CmdType.start);
 
     }
 
     @Test
     public void shouldRecognizeRunActivityCmd() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{ "run", "type=runwoot" });
+        NBCLIOptions opts = new NBCLIOptions(new String[]{ "run", "type=runwoot" });
-        List<EBCLIOptions.Cmd> cmds = opts.getCommands();
+        List<NBCLIOptions.Cmd> cmds = opts.getCommands();
         assertThat(cmds).hasSize(1);
-        assertThat(cmds.get(0).getCmdType()).isEqualTo(EBCLIOptions.CmdType.run);
+        assertThat(cmds.get(0).getCmdType()).isEqualTo(NBCLIOptions.CmdType.run);
 
     }
 
     @Test
     public void shouldRecognizeStopActivityCmd() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{ "stop", "woah" });
+        NBCLIOptions opts = new NBCLIOptions(new String[]{ "stop", "woah" });
-        List<EBCLIOptions.Cmd> cmds = opts.getCommands();
+        List<NBCLIOptions.Cmd> cmds = opts.getCommands();
         assertThat(cmds).hasSize(1);
-        assertThat(cmds.get(0).getCmdType()).isEqualTo(EBCLIOptions.CmdType.stop);
+        assertThat(cmds.get(0).getCmdType()).isEqualTo(NBCLIOptions.CmdType.stop);
         assertThat(cmds.get(0).getCmdSpec()).isEqualTo("woah");
 
     }
 
     @Test(expectedExceptions = InvalidParameterException.class)
     public void shouldThrowErrorForInvalidStopActivity() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{ "stop", "woah=woah" });
+        NBCLIOptions opts = new NBCLIOptions(new String[]{ "stop", "woah=woah" });
-        List<EBCLIOptions.Cmd> cmds = opts.getCommands();
+        List<NBCLIOptions.Cmd> cmds = opts.getCommands();
     }
 
     @Test
     public void shouldRecognizeAwaitActivityCmd() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{ "await", "awaitme" });
+        NBCLIOptions opts = new NBCLIOptions(new String[]{ "await", "awaitme" });
-        List<EBCLIOptions.Cmd> cmds = opts.getCommands();
+        List<NBCLIOptions.Cmd> cmds = opts.getCommands();
-        assertThat(cmds.get(0).getCmdType()).isEqualTo(EBCLIOptions.CmdType.await);
+        assertThat(cmds.get(0).getCmdType()).isEqualTo(NBCLIOptions.CmdType.await);
         assertThat(cmds.get(0).getCmdSpec()).isEqualTo("awaitme");
 
     }
 
     @Test(expectedExceptions = InvalidParameterException.class)
     public void shouldThrowErrorForInvalidAwaitActivity() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{ "await", "awaitme=notvalid" });
+        NBCLIOptions opts = new NBCLIOptions(new String[]{ "await", "awaitme=notvalid" });
-        List<EBCLIOptions.Cmd> cmds = opts.getCommands();
+        List<NBCLIOptions.Cmd> cmds = opts.getCommands();
 
     }
 
     @Test
     public void shouldRecognizewaitMillisCmd() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{ "waitmillis", "23234" });
+        NBCLIOptions opts = new NBCLIOptions(new String[]{ "waitmillis", "23234" });
-        List<EBCLIOptions.Cmd> cmds = opts.getCommands();
+        List<NBCLIOptions.Cmd> cmds = opts.getCommands();
-        assertThat(cmds.get(0).getCmdType()).isEqualTo(EBCLIOptions.CmdType.waitmillis);
+        assertThat(cmds.get(0).getCmdType()).isEqualTo(NBCLIOptions.CmdType.waitmillis);
         assertThat(cmds.get(0).getCmdSpec()).isEqualTo("23234");
 
     }
 
     @Test(expectedExceptions = NumberFormatException.class)
     public void shouldThrowErrorForInvalidWaitMillisOperand() {
-        EBCLIOptions opts = new EBCLIOptions(new String[]{ "waitmillis", "noway" });
+        NBCLIOptions opts = new NBCLIOptions(new String[]{ "waitmillis", "noway" });
-        List<EBCLIOptions.Cmd> cmds = opts.getCommands();
+        List<NBCLIOptions.Cmd> cmds = opts.getCommands();
 
     }
 

engine-core/pom.xml

@@ -5,7 +5,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -28,7 +28,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>

engine-core/src/main/java/io/nosqlbench/engine/core/metrics/MetricsContext.java

@@ -27,7 +27,7 @@ public class MetricsContext implements MetricRegistryService {
     private static MetricsContext instance;
 
     private MetricReporters metricReporters = MetricReporters.getInstance();
-    private MetricRegistry metrics = new EBMetricsRegistry();
+    private MetricRegistry metrics = new NBMetricsRegistry();
 
     public static MetricsContext getInstance() {
         synchronized (MetricsContext.class) {

engine-core/src/main/java/io/nosqlbench/engine/core/metrics/NBMetricsRegistry.java

@@ -23,7 +23,7 @@ import com.codahale.metrics.MetricRegistry;
 import com.codahale.metrics.Timer;
 import org.mpierce.metrics.reservoir.hdrhistogram.HdrHistogramReservoir;
 
-public class EBMetricsRegistry extends MetricRegistry {
+public class NBMetricsRegistry extends MetricRegistry {
 
     @Override
     public Timer timer(String name) {

engine-docker/pom.xml

@@ -4,7 +4,7 @@
   <parent>
     <artifactId>mvn-defaults</artifactId>
     <groupId>io.nosqlbench</groupId>
-    <version>3.12.30-SNAPSHOT</version>
+    <version>3.12.42-SNAPSHOT</version>
     <relativePath>../mvn-defaults</relativePath>
   </parent>
 
@@ -87,7 +87,7 @@
     <dependency>
       <groupId>io.nosqlbench</groupId>
       <artifactId>engine-api</artifactId>
-      <version>3.12.30-SNAPSHOT</version>
+      <version>3.12.42-SNAPSHOT</version>
     </dependency>
   </dependencies>
 

engine-docs/pom.xml

@@ -4,7 +4,7 @@
   <parent>
     <artifactId>mvn-defaults</artifactId>
     <groupId>io.nosqlbench</groupId>
-    <version>3.12.30-SNAPSHOT</version>
+    <version>3.12.42-SNAPSHOT</version>
     <relativePath>../mvn-defaults</relativePath>
   </parent>
 
@@ -29,7 +29,7 @@
     <dependency>
       <groupId>io.nosqlbench</groupId>
       <artifactId>docsys</artifactId>
-      <version>3.12.30-SNAPSHOT</version>
+      <version>3.12.42-SNAPSHOT</version>
     </dependency>
 
   </dependencies>

engine-docs/src/main/resources/docs-for-nb/00_nosqlbench/02_downloading.md

@@ -0,0 +1,24 @@
+---
+title: Getting NoSQLBench
+weight: 3
+---
+
+NoSQLBench is packaged directly as a Linux binary named `nb` and as
+an executable Java jar named `nb.jar`.
+
+The Linux binary is recommended, since it comes with its own
+JVM and eliminates the need to manage Java downloads. Both can be obtained
+at the releases section of the main NoSQLBench project:
+
+- [NoSQLBench Releases](https://github.com/nosqlbench/nosqlbench/releases)
+
+
+:::info
+Once you download the binary, you may need to `chmod +x nb` to make it
+executable.
+:::
+
+:::info
+If you choose to use the nb.jar instead of the binary, it is recommended
+to run it with at least Java 12.
+:::

engine-docs/src/main/resources/docs-for-nb/00_nosqlbench/04_support_options.md

@@ -0,0 +1,26 @@
+---
+title: Support Options
+weight: 10
+---
+
+# Support Options
+
+These guidelines are mirrored at the [Submitting Feedback](https://github.com/nosqlbench/nosqlbench/wiki/Submitting-Feedback)
+wiki page at the nosqlbench project site, which is also where any `[Submit Feedback]` links should will take you.
+
+## Bug Fixes
+
+If you think you have found a bug, please [file a bug report](https://github.com/nosqlbench/nosqlbench/issues/new?labels=bug).
+nosqlbench is actively used within DataStax, and verified bugs will get attention as resources permit. Bugs reports which are
+more detailed, or bug reports which include steps to reproduce will get attention first.
+
+## Feature Requests
+
+If you would like to see something in nosqlbench that is not there yet,
+please [submit a feature request](https://github.com/nosqlbench/nosqlbench/issues/new?labels=feature).
+
+## Documentation Requests
+
+If you would like to see a specific nosqlbench or testing topic added to the guidebook, please
+[request docs content](https://github.com/nosqlbench/nosqlbench/issues/new?labels=docs).
+

engine-docs/src/main/resources/docs-for-nb/00_nosqlbench/index.md

@@ -0,0 +1,67 @@
+---
+title: NoSQLBench Intro
+weight: 0
+---
+
+## Welcome to NoSQLBench
+
+Welcome to the documentation for NoSQLBench. This is a power tool that emulates real application workloads.
+This means that you can fast-track performance, sizing and data model testing without writing your own testing harness.
+
+## What is NoSQLBench?
+
+NoSQLBench is a serious performance testing tool for the NoSQL ecosystem.
+
+**NoSQLBench brings advanced testing capabilities into one tool that are not found in other testing tools.**
+
+- You can run common testing workloads directly from the command line. You
+  can start doing this within 5 minutes of reading this.
+- You can generate virtual data sets of arbitrary size, with deterministic
+  data and statistically shaped values.
+- You can design custom workloads that emulate your application, contained
+  in a single file, based on statement templates - no IDE or coding required.
+- You can immediately plot your results in a docker and grafana stack on Linux
+  with a single command line option.
+- When needed, you can open the access panels and rewire the runtime behavior
+  of NoSQLBench to do advanced testing, including a full scripting environment
+  with Javascript.
+
+The core machinery of NoSQLBench has been built with attention to detail.
+It has been battle tested within DataStax as a way to help users validate their
+data models, baseline system performance, and qualify system designs for scale.
+
+In short, NoSQLBench wishes to be a programmable power tool for performance
+testing. However, it is somewhat generic. It doesn't know directly about a
+particular type of system, or protocol. It simply provides a suitable machine
+harness in which to put your drivers and testing logic. If you know how to build
+a client for a particular kind of system, EB will let you load it like a plugin
+and control it dynamically.
+
+Initially, NoSQLBench comes with support for CQL, but we would like to see this
+expanded with contributions from others.
+
+## Origins
+
+The code in this project comes from multiple sources. The procedural data
+generation capability was known before as 'Virtual Data Set'. The core runtime
+and scripting harness was from the 'EngineBlock' project. The CQL support was
+previously used within DataStax. In March of 2020, DataStax and the project
+maintainers for these projects decided to put everything into one OSS project
+in order to make contributions and sharing easier for everyone. Thus, the new
+project name and structure was launched as nosqlbench.io. NoSQLBench is an
+independent project that is primarily sponsored by DataStax.
+
+We offer NoSQLBench as a new way of thinking about testing systems. It is not
+limited to testing only one type of system. It is our wish to build a community
+of users and practice around this project so that everyone in the NoSQL ecosystem
+can benefit from common concepts and understanding and reliable patterns of use.
+
+## Scalable User Experience
+
+NoSQLBench endeavors to be valuable to all users. We do this by making it easy for you, our user, to
+do just what you need without worrying about the rest. If you need to do something simple, it should
+be simple to find the right settings and just do it. If you need something more sophisticated, then you
+should be able to find what you need with a reasonable amount of effort and no surprises.
+
+That is the core design principle behind NoSQLBench. We hope you like it.
+

engine-docs/src/main/resources/docs-for-nb/01_nosqlbench/02_compatibility.md

@@ -1,25 +0,0 @@
----
-title: Compatibility
-weight: 3
----
-
-# Binary Format
-
-nosqlbench is distributed primarily as a binary for Linux distributions. The nosqlbench binary includes its own OpenJDK runtime. It should work for most modern Linux distributions. The only requirement is that fuse be installed (it is usually already present) on the client system.
-
-# Supported Systems
-
-nosqlbench runs on Linux as a binary distribution. Any modern Linux which can run AppImage binaries should work.
-
-# Activity Types
-
-In nosqlbench terms, this means:
-
-Activity types are how nosqlbench gets its support for different protocols or client drivers. The initial release of nosqlbench includes support for
-these activity types:
-
-- The CQL activity type
-  - The initial release of the CQL activity type uses the DataStax driver version 1.9.0
-- The stdout activity type.
-
-

engine-docs/src/main/resources/docs-for-nb/01_nosqlbench/03_release_notes.md

@@ -1,18 +0,0 @@
----
-title: Release Notes
-weight: 5
----
-
-# Release Notes
-
-The enhancements, fixes, and usage notes that go with each release
-will be summarized here.
-
-## Initial Release
-
-- Release Date: 01/29/2020
-- System Requirements:
-  - Any recent Linux system with FUSE support
-- Supported Activity Types:
-  - cql
-  - stdout

engine-docs/src/main/resources/docs-for-nb/01_nosqlbench/04_support_options.md

@@ -1,22 +0,0 @@
----
-title: Support Options
-weight: 10
----
-
-# Support Options
-
-These guidelines are mirrored at the [Submitting Feedback](https://github.com/nosqlbench/nosqlbench/wiki/Submitting-Feedback) wiki page at the nosqlbench project site, which is also where the `[Submit Feedback]` link will take you.
-
-## Bug Fixes
-
-If you think you have found a bug, please [file a bug report](https://github.com/nosqlbench/nosqlbench/issues/new?labels=bug). nosqlbench is actively used within DataStax, and verified bugs will get attention as resources permit. Bugs reports which are more detailed, or bug reports which include steps to reproduce will get attention first.
-
-## Feature Requests
-
-If you would like to see something in nosqlbench that is not there yet,
-please [submit a feature request](https://github.com/nosqlbench/nosqlbench/issues/new?labels=feature).
-
-## Documentation Requests
-
-If you would like to see a specific nosqlbench or testing topic added to the guidebook, please [request docs content](https://github.com/nosqlbench/nosqlbench/issues/new?labels=docs).
-

engine-docs/src/main/resources/docs-for-nb/01_nosqlbench/05_troubleshooting.md

@@ -1,24 +0,0 @@
----
-title: Troubleshooting
-weight: 05
----
-
-# Troubleshooting
-
-This section will contain some troubleshooting guidance for
-common issue as we uncover them.
-
-## Errors while starting nosqlbench binary
-
-If you get an error while trying to run the Linux nosqlbench binary, ensure that you have the system module installed for fuse. This module is used by the AppImage runtime that allows for a bundled binary.
-
-## Errors when running java -jar
-
-### Verify java binary path
-
-You will need to make sure that the java binary is the correct one that is being run. Either call it with the full path `/usr/local/...` or use `which java` to see which java executable is used when you just run `java ...`.
-
-### Verify java version
-
-Each version of nosqlbench requires a particular major version of Java. For example, nosqlbench version 2.12.26 requires at least Java 12.
-You can quickly check which version of java you have on your path with `java -version`

engine-docs/src/main/resources/docs-for-nb/01_nosqlbench/index.md

@@ -1,16 +0,0 @@
----
-title: Introducing nosqlbench
-weight: 10
----
-
-# nosqlbench docs
-
-Welcome to the documentation for nosqlbench. nosqlbench is a power tool that emulates real application workloads. This means that you can fast-track performance, sizing and data model testing without writing your own testing harness.
-
-nosqlbench endeavors to be valuable to all users. We do this by making it easy for you, our user, to do just what you need without worrying about the rest. If you need to do something simple, it should be simple to find the right settings and just do it. If you need something more sophisticated, then you should be able to find what you need with a reasonable amount of effort and no surprises.
-
-Doing this well requires a coordinated effort in how the tools are documented and layered. We're just getting started with the bundled
-docs that you are reading now. Look for new and expanded content in this guidebook with each release. We will be adding docs for more advanced users to unlock based on a how-to format.
-
-We take requests! If you have specific nosqlbench topics you'd like to
-have added to this guidebook, please make a request as described under the Support Options section.

engine-docs/src/main/resources/docs-for-nb/01_showcase/advanced_testing.md

@@ -0,0 +1,92 @@
+---
+title: Advanced Testing
+weight: 13
+---
+
+:::info
+Some of the features discussed here are only for advanced testing scenarios.
+:::
+
+
+## Hybrid Rate Limiting
+
+Rate limiting is a complicated endeavor, if you want to do it well. The basic
+rub is that going fast means you have to be less accurate, and vice-versa.
+As such, rate limiting is a parasitic drain on any system. The act of rate
+limiting is in and of itself poses a limit to the maximum rate, regardless
+of the settings you pick, because this forces your system to interact with
+some hardware notion of time passing, and this takes CPU cycles that could
+be going to the thing you are limiting.
+
+This means that in practice, rate limiters are often very featureless. It's
+daunting enough to need rate limiting, and asking for anything more than
+that is often wishful thinking. Not so in NoSQLBench.
+
+The rate limiter in NoSQLBench provides a comparable degree of performance
+and accuracy to others found in the Java ecosystem, but it *also* has advanced
+features:
+
+- Allows a sliding scale between average rate limiting and strict rate limiting.
+- Internally accumulates delay time, for C.O. friendly metrics
+- It is resettable and reconfigurable on the fly
+- It provides its configured values in addition to performance data in metrics
+
+## Flexible Error Handling
+
+An emergent facility in NoSQLBench is the way that error are handled within
+an activity. For example, with the CQL activity type, you are able to route
+error handling for any of the known exception types. You can count errors,
+you can log them. You can cause errored operations to  auto-retry if possible,
+up to a configurable number of tries.
+
+This means, that as a user, you get to decide what your test is about. Is it
+about measuring some nominal but anticipated level of errors due to intentional
+over-saturation? If so, then count the errors, and look at their histogram data
+for timing details within the available timeout.
+
+Are you doing a basic stability test, where you want the test to error out
+for even the slightest error? You can configure for that if you need.
+
+## Cycle Logging
+
+It is possible to record the result status of each and every cycles in
+a NoSQLBench test run. If the results are mostly homogeneous, the RLE
+encoding of the results will reduce the output file down to a small
+fraction of the number of cycles. The errors are mapped to ordinals, and
+these ordinals are stored into a direct RLE-encoded log file. For most
+testing where most of the result are simply success, this file will be tiny.
+You can also convert the cycle log into textual form for other testing
+and post-processing and vice-versa.
+
+## Op Sequencing
+
+The way that operations are planned for execution in NoSQLBench is based on
+a stable ordering that is configurable. The statement forms are mixed
+together based on their relative ratios. The three schemes currently supported
+are round-robin with exhaustion (bucket), duplicate in order (concat), and
+a way to spread each statement out over the unit interval (interval). These
+account for most configuration scenarios without users having to micro-manage
+their statement templates.
+
+## Sync and Async
+
+There are two distinct usage modes in NoSQLBench when it comes to operation
+dispatch and thread management:
+
+### Sync
+
+Sync is the default form. In this mode, each thread reads its sequence
+and dispatches one statement at a time, holding only one operation in flight
+per thread. This is the mode you often use when you want to emulate an
+application's request-per-thread model, as it implicitly linearizes the
+order of operations within the computed sequence of statements.
+
+### Async
+
+In Async mode, each thread in an activity is reponsible for juggling a number
+of operations in-flight. This allows a NoSQLBench client to juggle an
+arbitrarily high number of connections, limited primarily by how much memory
+you have.
+
+Internally, the Sync and Async modes have different code paths. It is possible
+for an activity type to support one or both of these.

engine-docs/src/main/resources/docs-for-nb/01_showcase/battle_tested_ideas.md

@@ -0,0 +1,63 @@
+---
+title: Core Concepts
+weight: 2
+---
+
+The core concepts that NoSQLBench is built on have been scrutinized,
+replaced, refined, and hardened through several years of use
+by users of various needs and backgrounds.
+
+This is important when trying to find a way to express common patterns
+in what is often a highly fragmented practice. Testing is hard. Scale
+testing is hard. Distributed testing is hard. We need a set of conceptual
+building blocks that can span across workloads and system types, and
+machinery to put these concepts to use. Some concepts used in NoSQLBench
+are shared below for illustration, but this is by no means an exhaustive
+list.
+
+### The Cycle
+
+Cycles in NoSQLBench are whole numbers on a number line. All operations
+in a NoSQLBench session are derived from a single cycle. It's a long value,
+and a seed. The cycle determines not only which statements (of those available)
+will get executed, but it also determines what the values bound to that
+statement will be.
+
+Cycles are specified as a closed-open `[min,max)` interval, just as slices
+in some languages. That is, the min value is included in the range, but the
+max value is not. This means that you can stack slices using common numeric
+reference points without overlaps or gaps. It means you can have exact awareness
+of what data is in your dataset, even incrementally.
+
+You can think of a cycle as a single-valued coordinate system for data that
+lives adjacent to that number on the number line.
+
+### The Activity
+
+An activity is a multi-threaded flywheel of statements in some sequence
+and ratio. Activities run over the numbers in a cycle range. Each activity
+has a driver type which determines the native protocol that it speaks.
+
+An activity continuously
+
+### The Activity Type
+
+An activity type is a high level driver for a protocol. It is like a
+statement-aware cartridge that knows how to take a basic statement template
+and turn it into an operation for the scenario to execute.
+
+### The Scenario
+
+The scenario is a runtime session that holds the activities while they run.
+A NoSQLBench scenario is responsible for aggregating global runtime settings,
+metrics reporting channels, logfiles, and so on.
+
+### The Scenario Script
+
+Each scenario is governed by a script runs single-threaded, asynchronously
+from activities, but in control of activities. If needed, the scenario script
+is automatically created for the user, and the user never knows it is there.
+If the user has advanced testing requirements, then they may take advantage
+of the scripting capability at such time.
+When the script exits, *AND* all activities are complete, then the scenario
+is complete..

engine-docs/src/main/resources/docs-for-nb/01_showcase/hifi_metrics.md

@@ -0,0 +1,47 @@
+---
+title: High Fidelity Metrics
+weight: 12
+---
+
+## Discrete Reservoirs
+
+In NoSQLBench, we avoid the use of time-decaying metrics reservoirs.
+Internally, we use HDR reservoirs with discrete time boundaries. This
+is so that you can look at the min and max values and know that they
+apply accurately to the whole sampling window.
+
+## Metric Naming
+
+All activity types that run have a symbolic alias that identifies
+them for the purposes of automation and metrics. If you have multiple
+activities running concurrently, they will have different names and will
+be represnted distinctly in the metrics flow.
+
+## Precision and Units
+
+By default, the internal HDR histogram reservoirs are kept at 4 digits
+of precision. All timers are kept at nanosecond resolution.
+
+## Metrics Reportring
+
+Metrics can be reported via graphite as well as CSV, logs, HDR logs, and
+HDR stats summary CSV files.
+
+## Coordianated Omission
+
+The metrics naming and semantics in NoSQLBench are setup so that you
+can have coordinated omission metrics when they are appropriate, but
+there are no there changes when they are not. This means that the metric
+names and meanings remain stable in any case.
+
+Particularly, NoSQLBench avoids the term "latency" altogether as it is often overused
+and thus prone to confusing people.
+
+Instead, the terms `service time`, `wait time`, and `response time` are used.
+These are abbreviated in metrics as `servicetime`, `waittime`, and `responsetime`.
+
+The `servicetime` metric is the only one which is always present. When a
+rate limiter is used, then additionally `waittime` and `responsetime` are
+reported.
+
+

engine-docs/src/main/resources/docs-for-nb/01_showcase/index.md

@@ -0,0 +1,25 @@
+---
+title: NoSQLBench Showcase
+weight: 10
+---
+
+Since NoSQLBench is new on the scene in its current form, you may be wondering
+why you would want to use it over any other tool. That is what this section is all
+about.
+
+If you want to look under the hood of this toolkit before giving it a spin,
+this section is for you. You don't have to read all of this! It is here for those
+who want to know the answer to the question "So, what's the big deal??"
+Just remember it is here for later if you want to skip to the next section and get
+started testing.
+
+NoSQLBench can do nearly everything that other testing tools can do, and more. It
+achieves this by focusing on a scalable user experience in combination with a
+modular internal architecture.
+
+NoSQLBench is a workload construction and simulation tool for scalable systems
+testing. That is an entirely different scope of endeavor than most other tools.
+
+The pages in this section all speak to advanced capabilities that are unique
+to NoSQLBench. In time, we want to show these with basic scenario examples, right
+in the docs.

engine-docs/src/main/resources/docs-for-nb/01_showcase/modular_architecture.md

@@ -0,0 +1,25 @@
+---
+title: Modular Architecture
+weight: 11
+---
+
+The internal architecture of NoSQLBench is modular throughout.
+Everything from the scripting extensions to the data generation functions
+is enumerated at compile time into a service descriptor, and then discovered
+at runtime by the SPI mechanism in Java.
+
+This means that extending and customizing bundles and features is quite
+manageable.
+
+It also means that it is relatively easy to provide a suitable
+API for multi-protocol support. In fact, there are several drivers
+avaialble in the current NoSQLBench distribution. You can list them
+out with `./nb --list-activity-types`, and you can get help on
+how to use each of them with `./nb help <name>`.
+
+This also is a way for us to encourage and empower other contributors
+to help develop the capabilities and reach of NoSQLBench as a bridge
+building tool in our community. This level of modularity is somewhat
+unusual, but it serves the purpose of helping users with new features.
+
+

engine-docs/src/main/resources/docs-for-nb/01_showcase/portable_workloads.md

@@ -0,0 +1,49 @@
+---
+title: Portable Workloads
+weight: 2
+---
+
+All of the workloads that you can build with NoSQLBench are self-contained
+in a workload file. This is a statement-oriented configuration file that
+contains templates for the operations you want to run in a workload.
+
+This defines part of an activity - the iterative flywheel part that is
+run directly within an activity type.  This file contains everything needed
+to run a basic activity -- A set of statements in some ratio. It can be
+used to start an activity, or as part of several activities within a scenario.
+
+## Standard YAML Format
+
+The format for describing statements in NoSQLBench is generic, but in a
+particular way that is specialized around describing statements for a workload.
+
+That means that you can use the same YAML format to describe a workload
+for kafka as you can for Apache Cassandra or DSE.
+
+The YAML structure has been tailored to describing statements, their
+data generation bindings, how they are grouped and selected, and the
+parameters needed by drivers, like whether they should be prepared
+statements or not.
+
+Further, the YAML format allows for defaults and overrides with a
+very simple mechanism that reduces editing fatigue for frequent users.
+
+You can also template document-wide macro paramers which are taken
+from the command line parameters just like any other parameter. This is
+a way of templating a workload and make it multi-purpose or adjustable
+on the fly.
+
+## Experimentation Friendly
+
+Because the workload YAML format is generic across activity types,
+it is possible to ask one acivity type to interpret the statements that are
+meant for another. This isn't generally a good idea, but it becomes
+extremely handy when you want to have a very high level activity type like
+`stdout` use a lower-level syntax like that of the `cql` activity type.
+When you do this, the stdout activity type _plays_ the statements to your
+console as they would be executed in CQL, data bindings and all.
+
+This means you can empirically and substantively demonstrate and verify
+access patterns, data skew, and other dataset details before you
+change back to cql mode and turn up the settings for a higher scale test.
+

engine-docs/src/main/resources/docs-for-nb/01_showcase/scripting_environment.md

@@ -0,0 +1,93 @@
+---
+title: Scripting Environment
+weight: 3
+---
+
+The ability to write open-ended testing simulations is provided in
+EngineBlock by means of a scripted runtime, where each scenario is
+driven from a control script that can do anything the user wants.
+
+## Dynamic Parameters
+
+Some configuration parameters of activities are designed to be
+assignable while a workload is running. This makes things like
+threads, rates, and other workload dynamics pseudo real-time.
+The internal APIs work with the scripting environment to expose
+these parameters directly to scenario scripts.
+
+## Scripting Automatons
+
+When a NoSQLBench scenario is running, it is under the control of a
+single-threaded script. Each activity that is started by this script
+is run within its own threadpool, asynchronously.
+
+The control script has executive control of the activities, as well
+as full visibility into the metrics that are provided by each activity.
+The way these two parts of the runtime meet is through the service
+objects which are installed into the scripting runtime. These service
+objects provide a named access point for each running activity and its
+metrics.
+
+This means that the scenario script can do something simple, like start
+activities and wait for them to complete, OR, it can do something
+more sophisticated like dynamically and interative scrutinize the metrics
+and make realtime adjustments to the workload while it runs.
+
+## Analysis Methods
+
+Scripting automatons that do feedback-oriented analysis of a target system
+are called analysis methods in NoSQLBench. We have prototypes a couple of
+these already, but there is nothing keeping the adventurous from coming up
+with their own.
+
+## Command Line Scripting
+
+The command line has the form of basic test commands and parameters.
+These command get converted directly into scenario control script
+in the order they appear. The user can choose whether to stay in
+high level executive mode, with simple commands like "run yaml=...",
+or to drop down directly into script design. They can look at the
+equivalent script for any command line by running --show-script.
+If you take the script that is dumped to console and run it, it should
+do exactly the same thing as if you hadn't even looked at it and just
+the standard commands.
+
+There are even ways to combine script fragments, full commands, and calls
+to scripts on the command line. Since each variant is merely a way of
+constructing scenario script, they all get composited together before
+the scenario script is run.
+
+New introductions to NoSQLBench should focus on the command line. Once
+a user is familiar with this, it is up to them whether to tap into the
+deeper functionality. If they don't need to know about scenario scripting,
+then they shouldn't have to learn about it to be effective.
+
+## Compared to DSLs
+
+Other tools may claim that their DSL makes scenario "simulation" easier.
+In practice, any DSL is generally dependent on a development tool to
+lay the language out in front of a user in a fluent way. This means that
+DSLs are almost always developer-targeted tools, and mostly useless for
+casual users who don't want to break out an IDE.
+
+One of the things a DSL proponent may tell you is that it tells you
+"all the things you can do!". This is de-facto the same thing as it
+telling you "all the things you can't do" because it's not part of the
+DSL. This is not a win for the user. For DSL-based systems, the user
+has to use the DSL whether or not it enhances their creative control,
+while in fact, most DSL aren't rich enough to do much that is interesting
+from a simulation perspective.
+
+In NoSQLBench, we don't force the user to use the programming abstractions
+except at a very surface level -- the CLI. It is up to the user whether
+or not to open the secret access panel for the more advance functionality.
+If they decide to do this, we give them a commodity language (ECMAScript),
+and we wire it into all the things they were already using. We don't take
+away their expressivity by telling them what they can't do. This way,
+users can pick their level of investment and reward as best fits thir individual
+needs, as it should be.
+
+## Scripting Extensions
+
+Also mentioned under the section on modularity, it is relatively easy
+for a developer to add their own scripting extensions into NoSQLBench.

engine-docs/src/main/resources/docs-for-nb/01_showcase/virtual_datasets.md

@@ -0,0 +1,94 @@
+---
+title: Virtual DataSets
+weight: 1
+---
+
+The _Virtual Dataset_ capabilities within NoSQLBench allow you to
+generate data on the fly. There are many reasons for using this technique
+in testing, but it is often a topic that is overlooked or taken for granted.
+
+## Industrial Strength
+
+The algorithms used to generate data are based on
+advanced techniques in the realm of variate sampling. The authors have
+gone to great lengths to ensure that data generation is efficient and
+as much O(1) in processing time as possible.
+
+For example...
+
+One technique that is used to achieve this is to initialize and cache
+data in high resolution look-up tables for distributions which may perform
+differently depending on their density functions. The existing Apache
+Commons Math libraries have been adapted into a set of interpolated
+Inverse Cumulative Distribution sampling functions. This means that
+you can use a Zipfian distribution in the same place as you would a
+Uniform distribution, and once initialized, they sample with identical
+overhead. This means that by changing your test definition, you don't
+accidentally change the behavior of your test client.
+
+## The Right Tool
+
+Many other testing systems avoid building a dataset generation component.
+It's a toubgh problem to solve, so it's often just avoided. Instead, they use
+libraries like "faker" and variations on that. However, faker is well named,
+no pun intended. It was meant as a vignette library, not a source of test
+data for realistic results. If you are using a testing tool for scale testing
+and relying on a faker variant, then you will almost certainly get invalid
+results for any serious test.
+
+The virtual dataset component of NoSQLBench is a library that was designed
+for high scale and realistic data streams.
+
+## Deterministic
+
+The data that is generated by the virtual dataset libraries is determinstic.
+This means that for a given cycle in a test, the operation that is synthesized
+for that cycle will be the same from one session to the next. This is intentional.
+If you want to perturb the test data from one session to the next, then you can
+most easily do it by simply selecting a different set of cycles as your basis.
+
+This means that if you find something intersting in a test run, you can go
+back to it just by specifying the cycles in question. It also means that you
+aren't losing comparative value between tests with additional randomness thrown
+in. The data you generate will still look random to the human eye, but that doesn't
+mean that it can't be reproducible.
+
+## Statistically Shaped
+
+All this means is that the values you use to tie your dataset together
+can be specific to any distribution that is appropriate. You can ask for
+a stream of floating point values 1 trillion values long, in any order.
+You can use discrete or continuous distributions, with whatever parameters
+you need.
+
+## Best of Both Worlds
+
+Some might worry that fully synthetic testing data is not realistic enough.
+The devil is in the details on these arguments, but suffice it to say that
+you can pick the level of real data you use as seed data with NoSQLBench.
+
+For example, using the alias sampling method and a published US census
+(public domain) list of names and surnames tha occured more than 100x,
+we can provide extremely accurate samples of names according to the
+discrete distribution we know of. The alias method allows us to sample
+accurately in O(1) time from the entire dataset by turning a large number
+of weights into two uniform samples. You will simply not find a better way
+to sample names of US names than this. (but if you do, please file an issue!)
+
+## Java Idiomatic Extension
+
+The way that the virtual dataset component works allows Java developers to
+write any extension to the data generation functions simply in the form
+of Java 8 or newer Funtional interfaces. As long as they include the
+annotation processor and annotate their classes, they will show up in the
+runtime and be available to any workload by their class name.
+
+## Binding Recipes
+
+It is possible to stitch data generation functions together directly in
+a workload YAML. These are data-flow sketches of functions that can
+be copied and pasted between workload descriptions to share or remix
+data streams. This allows for the adventurous to build sophisticated
+virtual datasets that emulate nuances of real datasets, but in a form
+that takes up less space on the screen than this paragraph!
+

engine-docs/src/main/resources/docs-for-nb/02_getting_started/01_example_commands.md

@@ -1,19 +1,19 @@
 ---
-title: 02 Running
+title: 01 Commands
 weight: 2
 ---
 
-# 2. Running nosqlbench
+Let's run a simple test against a cluster to establish some basic familiarity with the NoSQLBench.
 
-Now that we have nosqlbench installed, we will run a simple test against a DSE cluster to establish some basic familiarity with the tool.
+## Create a Schema
-
-## Create Schema
 
 We will start by creating a simple schema in the database.
 From your command line, go ahead and execute the following command,
 replacing the `host=<dse-host-or-ip>` with that of one of your database nodes.
 
-    ./nb run type=cql yaml=baselines/cql-keyvalue tags=phase:schema host=<dse-host-or-ip>
+```
+./nb run type=cql yaml=baselines/cql-keyvalue tags=phase:schema host=<dse-host-or-ip>
+```
 
 This command is creating the following schema in your database:
 
@@ -100,7 +100,7 @@ baselines/cql-keyvalue: 8.87%/Running (details: min=0 cycle=8868 max=100000)
 baselines/cql-keyvalue: 100.00%/Finished (details: min=0 cycle=100000 max=100000)
 ```
 
-## Run main workload
+## Run the main test phase
 
 Now that we have a base dataset of 100k rows in the database, we will now run a mixed read / write workload, by default this runs a 50% read / 50% write workload.
 

engine-docs/src/main/resources/docs-for-nb/02_getting_started/01_installing.md

@@ -1,29 +0,0 @@
----
-title: 01 Installing
-weight: 1
----
-
-# 1. Installing nosqlbench
-
-If you are viewing this via the guidebook, you've already completed this step and you can move on to the next section.
-
-If you are viewing this documentation as exported from the guidebook, then you need to get the binary or jar for your system.
-
-The binary is recommended, since it contains its own built-in JVM. If you are running Linux, get the nosqlbench binary for Linux.
-
-If you are running another system with a supported JVM, then you can do the following:
-
-1. Download nosqlbench.jar
-2. Download and install the JVM corresponding to the nosqlbench version. (The second number of the nosqlbench version indicates the JVM version). For example, nosqlbench version 2.13.4 would require JVM 13.
-3. Execute nosqlbench as `java -jar nosqlbench.jar ...`. You can replace the elipses `...` with any valid nosqlbench command line.
-
-If you have any trouble, check the troubleshooting section.
-
-
-## Sanity Check
-
-To ensure that nosqlbench runs on your system, simply run it as
-
-    nb --version
-
-

engine-docs/src/main/resources/docs-for-nb/02_getting_started/02_example_results.md

@@ -1,22 +1,24 @@
 ---
-title: 03 Getting Results
+title: 02 Results
 weight: 3
 ---
 
-# 3. Getting Results
+We just ran a very simple workload against our database. In that example, we saw that
-
+nosqlbench writes to a log file and it is in that log file where the most basic form of metrics are displayed.
-Coming off of our first run with nosqlbench, we ran a very simple workload against our database. In that example, we saw that nosqlbench writes to a log file and it is in that log file where the most basic form of metrics are displayed.
 
 ## Log File Metrics
 
 For our previous run, we saw that nosqlbench was writing to `logs/scenario_20190812_154431_028.log`
 
-Even when you don't configure nosqlbench to write its metrics to another location, it will periodically report all the metrics to the log file.
+Even when you don't configure nosqlbench to write its metrics to another location, it
-At the end of a scenario, before nosqlbench shuts down, it will flush the partial reporting interval again to the logs. This means you can always
+will periodically report all the metrics to the log file. At the end of a scenario,
-look in the logs for metrics information.
+before nosqlbench shuts down, it will flush the partial reporting interval again to
+the logs. This means you can always look in the logs for metrics information.
 
 :::warning
-If you look in the logs for metrics, be aware that the last report will only contain a partial interval of results. When looking at the last partial window, only metrics which average over time or which compute the mean for the whole test will be meaningful.
+If you look in the logs for metrics, be aware that the last report will only contain a
+partial interval of results. When looking at the last partial window, only metrics which
+average over time or which compute the mean for the whole test will be meaningful.
 :::
 
 

engine-docs/src/main/resources/docs-for-nb/02_getting_started/03_reading_metrics.md

@@ -1,17 +1,22 @@
 ---
-title: 04 Reading Metrics
+title: 03 Metrics
 weight: 4
 ---
 
-# 4. Reading Metrics
+A set of core metrics are provided for every workload that runs with nosqlbench,
-
+ regardless of the activity type and protocol used. This section explains each of
-A set of core metrics are provided for every workload that runs with nosqlbench, regardless of the activity type and protocol used. This section explains each of these metrics and shows an example of them from the log file.
+  these metrics and shows an example of them from the log file.
 
 ## metric: result
 
-This is the primary metric that should be used to get a quick idea of the throughput and latency for a given run. It encapsulates the entire operation life cycle ( ie. bind, execute, get result back ).
+This is the primary metric that should be used to get a quick idea of the
+throughput and latency for a given run. It encapsulates the entire
+operation life cycle ( ie. bind, execute, get result back ).
 
-For this example we see that we averaged 3732 operations / second with 3.6ms 75th percentile latency and 23.9ms 99th percentile latency. Note the raw metrics are in microseconds. This duration_unit may change depending on how a user configures nosqlbench, so always double-check it.
+For this example we see that we averaged 3732 operations / second with 3.6ms
+ 75th percentile latency and 23.9ms 99th percentile latency. Note the raw metrics are
+  in microseconds. This duration_unit may change depending on how a user configures
+  nosqlbench, so always double-check it.
 
 ```
 2019-08-12 15:46:01,310 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=TIMER, name=baselines/cql-keyvalue.result, count=100000, min=233.48, max=358596.607, mean=3732.00338612, stddev=10254.850416061185, median=1874.815, p75=3648.767, p95=10115.071, p98=15855.615, p99=23916.543, p999=111292.415, mean_rate=4024.0234405430424, m1=3514.053841156124, m5=3307.431472596865, m15=3268.6786509004132, rate_unit=events/second, duration_unit=microseconds
@@ -19,9 +24,13 @@ For this example we see that we averaged 3732 operations / second with 3.6ms 75t
 
 ## metric: result-success
 
-This metric shows whether there were any errors during the run. You can confirm that the count is equal to the number of cycles for the run if you are expecting or requiring zero failed operations.
+This metric shows whether there were any errors during the run. You can confirm that
+ the count is equal to the number of cycles for the run if
+  you are expecting or requiring zero failed operations.
 
-Here we see that all 100k of our cycles succeeded. Note that the metrics for throughput and latency here are slightly different than the `results` metric simply because this is a separate timer that only includes operations which completed with no exceptions.
+Here we see that all 100k of our cycles succeeded. Note that the metrics for throughput
+and latency here are slightly different than the `results` metric simply because this
+ is a separate timer that only includes operations which completed with no exceptions.
 
 ```
 2019-08-12 15:46:01,452 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=TIMER, name=baselines/cql-keyvalue.result-success, count=100000, min=435.168, max=358645.759, mean=3752.40990808, stddev=10251.524945886964, median=1889.791, p75=3668.479, p95=10154.495, p98=15884.287, p99=24280.063, p999=111443.967, mean_rate=4003.3090048756894, m1=3523.40328629036, m5=3318.8463896065778, m15=3280.480326762243, rate_unit=events/second, duration_unit=microseconds
@@ -29,16 +38,19 @@ Here we see that all 100k of our cycles succeeded. Note that the metrics for thr
 
 ## metric: resultset-size
 
-For read workloads, this metric shows the size of result sent back to nosqlbench from the server. This is useful to confirm that you are reading rows that already exist in the database.
+For read workloads, this metric shows the size of result sent back to nosqlbench
+from the server. This is useful to confirm that you are reading rows that already
+exist in the database.
 
-TODO: talk about mix of read / writes and how that affects this metric
 ```
 2019-08-12 15:46:00,298 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=HISTOGRAM, name=baselines/cql-keyvalue.resultset-size, count=100000, min=0, max=1, mean=8.0E-5, stddev=0.008943914131967056, median=0.0, p75=0.0, p95=0.0, p98=0.0, p99=0.0, p999=0.0
 ```
 
 #### metric: tries
 
-nosqlbench will retry failures 10 times by default, this is configurable via the `maxtries` command line option < link >. This metric shows a histogram of the number of tries that each operation required, in this example, there were no retries as the `count` is 100k.
+nosqlbench will retry failures 10 times by default, this is configurable via the `maxtries` command line
+option for the cql activity type. This metric shows a histogram of the number of tries that each operation
+required, in this example, there were no retries as the `count` is 100k.
 ```
 2019-08-12 15:46:00,341 INFO [main] i.e.c.ScenarioResult [Slf4jReporter.java:373] type=HISTOGRAM, name=baselines/cql-keyvalue.tries, count=100000, min=1, max=1, mean=1.0, stddev=0.0, median=1.0, p75=1.0, p95=1.0, p98=1.0, p99=1.0, p999=1.0
 ```
@@ -59,5 +71,8 @@ To get more information on these options, see the output of
 
 ### Congratulations
 
-You have completed your first run with nosqlbench! Let's head over to the Next Steps section < link > to talk about the possibilities that are now at our fingertips.
+You have completed your first run with nosqlbench!
+
+In the 'Next Steps' section, you'll find options for how to continue, whether you are looking
+for basic testing or something more advanced.
 

engine-docs/src/main/resources/docs-for-nb/02_getting_started/04_next_steps.md

@@ -0,0 +1,45 @@
+---
+title: Next Steps
+weight: 5
+---
+
+Now that you've run nosqlbench for the first time and seen what it does, you can
+choose what level of customization you want for further testing.
+
+The sections below describe key areas that users typically customize
+when working with nosqlbench.
+
+Everyone who uses nosqlbench will want to get familiar with the 'NoSQLBench Basics' section below.
+This is essential reading for new and experienced testers alike.
+
+## High-Level Users
+
+Several canonical workloads are already baked-in to nosqlbench for immediate use.
+If you are simply wanting to drive workloads from nosqlbench without building a custom workload,
+then you'll want to learn about the available workloads and their options.
+
+Recommended reading for high-level testing workflow:
+1. 'Built-In Workloads'
+2. 'nosqlbench Basics'
+
+## Workload Builders
+
+If you want to use nosqlbench to build a tailored workload that closely emulates what
+ a specific application would do, then you can build a YAML file that specifies all
+  of the details of an iterative workload. You can specify the access patterns,
+   data distributions, and more.
+
+The recommended reading for this is:
+
+1. 'NoSQLBench Basics'
+2. All of the 'Designing Workloads' section.
+3. The online examples (find the links in the Designing Workloads section.)
+
+## Scenario Developers
+
+The underlying runtime for a scenario in nosqlbench is based on EngineBlock,
+which means it has all the scripting power that comes with that. For advanced
+scenario designs, iterative testing models, or analysis methods, you can use
+ECMAScript to control the scenario from start to finish. This is an advanced
+ feature that is not recommended for first-time users. A guide for scenario
+ developers will be released in increments.

engine-docs/src/main/resources/docs-for-nb/02_getting_started/05_next_steps.md

@@ -1,35 +0,0 @@
----
-title: 05 Next Steps
-weight: 5
----
-
-# 5. Next Steps
-
-Now that you've run nosqlbench for the first time and seen what it does, you can choose what level of customization you want for further testing.
-
-The sections below describe key areas that users typically customize when working with nosqlbench.
-
-Everyone who uses nosqlbench will want to get familiar with the basics section below. This is essential reading for new and experienced testers alike.
-
-## High-Level Users
-
-Several canonical workloads are already baked-in to nosqlbench for immediate use. If you are simply wanting to drive workloads from nosqlbench without building a custom workload, then you'll want to learn about the available workloads and their options.
-
-Recommended reading for this is:
-1. 'Built-In Workloads'
-2. 'nosqlbench Basics'
-
-## Workload Builders
-
-If you want to use nosqlbench to build a tailored workload that closely emulates what a specific application would do, then you can build a YAML file that specifies all of the details of an iterative workload. You can specify the access patterns, data distributions, and more.
-
-The recommended reading for this is:
-
-1. 'nosqlbench Basics'
-2. All of the 'Designing Workloads' section.
-3. The online examples (find the links in the Designing Workloads section.)
-
-## Scenario Developers
-
-The underlying runtime for a scenario in nosqlbench is based on EngineBlock,
-which means it has all the scripting power that comes with that. For advanced scenario designs, iterative testing models, or analysis methods, you can use ECMAScript to control the scenario from start to finish. This is an advanced feature that is not recommended for first-time users. A guide for scenario developers will be released in increments.

engine-docs/src/main/resources/docs-for-nb/02_getting_started/index.md

@@ -1,9 +1,20 @@
 ---
-title: Getting Started
+title: Quick Start Example
 weight: 20
 ---
 
-# Getting Started
+If you are on Linux, you should be able to start getting useful results immediately with these commands:
 
-In this Getting Started track, we will walk you through your first test run with nosqlbench and explain the minimal set of information that you will need to get off the ground. We recommend that you go through the steps in this section in order, as each step builds on the last.
+1. `/nb  run type=cql yaml=baselines/cql-iot tags=phase:schema host=dsehost`
+2. `./nb run type=cql yaml=baselines/cql-iot tags=phase:main host=dsehost cycles=1M threads=auto host=dsehost`
 
+You can put your own contact points in place of `dsehost`.
+
+Alternately, if you have docker installed on your Linux system, and you have permissions to use it, you
+can use `--docker-metrics` to stand up a live metrics dashboard at port 3000.
+
+This example doesn't go into much detail about what it is doing. It is here to show you how quickly you can
+start running real workloads without having to learn much about the machinery that makes it happen.
+
+The rest of this section has a more elaborate example that exposes some of the basic options you may want to
+adjust for your first serious test.

engine-docs/src/main/resources/docs-for-nb/03_basics/01_command_line.md

@@ -1,10 +1,8 @@
 ---
-title: nosqlbench CLI Options
+title: NoSQLBench CLI Options
 weight: 01
 ---
 
-# nosqlbench CLI Options
-
 This is the same documentation you get in markdown format with the
 `nb --help` command.
 

engine-docs/src/main/resources/docs-for-nb/03_basics/index.md

@@ -1,5 +1,5 @@
 ---
-title: nosqlbench Basics
+title: NoSQLBench Basics
 weight: 30
 ---
 

engine-docs/src/main/resources/docs-for-nb/04_designing/statement_params.md

@@ -1,28 +0,0 @@
----
-title: Statement Params
-weight: 15
----
-
-Statement parameters apply to the defined operations for an activity. Statement
-parameters are always configurable as part of a `params` block in YAML, for
-activities that use the [Standard YAML](/user-guide/standard_yaml) format.
-
-In some cases, an [Activity Parameter](/parameters/activity_params) of the same
-name can be used to establish a default value. In that case, it will be
-documented here with the parameter description. 
-
-### ratio
-
-`ratio: <ratio>`
-
-Determines the frequency of the affected statements in the operational sequence.
-This means, in effect, the number of times a given statement will be executed
-within the planned sequence before it starts over at the beginning. When using ratio,
-it is important to be aware of *how* these statements are sequenced according
-to the ratio. That is controlled by [seq](/parameters/activity_params#seq).
-
-
-
-
-
-

engine-extensions/pom.xml

@@ -4,7 +4,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -22,7 +22,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>

mvn-defaults/pom.xml

@@ -3,7 +3,7 @@
 
     <groupId>io.nosqlbench</groupId>
     <artifactId>mvn-defaults</artifactId>
-    <version>3.12.30-SNAPSHOT</version>
+    <version>3.12.42-SNAPSHOT</version>
     <packaging>pom</packaging>
 
     <properties>
@@ -65,8 +65,14 @@
                 <artifactId>log4j-core</artifactId>
                 <version>2.13.0</version>
             </dependency>
-        </dependencies>
 
+            <dependency>
+              <groupId>com.github.oshi</groupId>
+              <artifactId>oshi-core</artifactId>
+              <version>4.5.0</version>
+            </dependency>
+
+        </dependencies>
     </dependencyManagement>
 
     <build>

nb/pom.xml

@@ -5,7 +5,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -24,61 +24,61 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-cli</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-docs</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-core</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>engine-extensions</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>activitytype-stdout</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>activitytype-diag</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>activitytype-tcp</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>activitytype-http</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>activitytype-cql</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>activitytype-cqlverify</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
 

nb/src/test/java/io/nosqlbench/cli/testing/ExitStatusIntegrationTests.java

@@ -51,17 +51,20 @@ public class ExitStatusIntegrationTests {
         assertThat(result.exitStatus).isEqualTo(2);
     }
 
-    @Test
+// Temporarily disabled for triage
-    public void testExitStatusOnActivityThreadException() {
+// TODO: figure out if github actions is an issue for this test.
-        ProcessInvoker invoker = new ProcessInvoker();
+// It passes locally, but fails spuriously in github actions runner
-        invoker.setLogDir("logs/test");
+//    @Test
-        ProcessResult result = invoker.run("exitstatus_threadexception", 30,
+//    public void testExitStatusOnActivityThreadException() {
-                "java", "-jar", JARNAME, "--logs-dir", "logs/test", "run", "type=diag", "throwoncycle=10", "cycles=20", "-vvv"
+//        ProcessInvoker invoker = new ProcessInvoker();
-        );
+//        invoker.setLogDir("logs/test");
-        String stdout = result.getStdoutData().stream().collect(Collectors.joining("\n"));
+//        ProcessResult result = invoker.run("exitstatus_threadexception", 30,
-        assertThat(stdout).contains("Diag was asked to throw an error on cycle 10");
+//                "java", "-jar", JARNAME, "--logs-dir", "logs/test", "run", "type=diag", "throwoncycle=10", "cycles=1000", "cyclerate=10", "-vvv"
-        assertThat(result.exitStatus).isEqualTo(2);
+//        );
-    }
+//        String stdout = result.getStdoutData().stream().collect(Collectors.joining("\n"));
+//        assertThat(stdout).contains("Diag was asked to throw an error on cycle 10");
+//        assertThat(result.exitStatus).isEqualTo(2);
+//    }
 
     @Test
     public void testExitStatusOnActivityAsyncStopException() {

nb/src/test/resources/scripts/async/cocycledelay_bursty.js

@@ -55,7 +55,7 @@ for (i = 0; i < 10; i++) {
     );
 
     scenario.waitMillis(1000);
-    if (metrics.co_cycle_delay.cycles.waittime.value < 10000000) {
+    if (metrics.co_cycle_delay.cycles.waittime.value < 50000000) {
         print("waittime trended back down as expected, exiting on iteration " + i);
         break;
     }

pom.xml

@@ -7,7 +7,7 @@
   <parent>
     <artifactId>mvn-defaults</artifactId>
     <groupId>io.nosqlbench</groupId>
-    <version>3.12.30-SNAPSHOT</version>
+    <version>3.12.42-SNAPSHOT</version>
     <relativePath>mvn-defaults</relativePath>
   </parent>
 

virtdata-annotations/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 

virtdata-api/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <groupId>io.nosqlbench</groupId>
         <artifactId>mvn-defaults</artifactId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -18,17 +18,17 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-processors</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-annotations</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-lang</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
 

virtdata-lang/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 

virtdata-lib-basics/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -35,7 +35,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>

virtdata-lib-curves4/pom.xml

@@ -4,7 +4,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -21,7 +21,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
 <!--        <dependency>-->

virtdata-lib-random/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -20,7 +20,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-api</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
 
         <dependency>

virtdata-lib-realer/pom.xml

@@ -4,7 +4,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -31,7 +31,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-lib-basics</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
     </dependencies>
 

virtdata-processors/pom.xml

@@ -7,7 +7,7 @@
     <parent>
         <artifactId>mvn-defaults</artifactId>
         <groupId>io.nosqlbench</groupId>
-        <version>3.12.30-SNAPSHOT</version>
+        <version>3.12.42-SNAPSHOT</version>
         <relativePath>../mvn-defaults</relativePath>
     </parent>
 
@@ -22,7 +22,7 @@
         <dependency>
             <groupId>io.nosqlbench</groupId>
             <artifactId>virtdata-annotations</artifactId>
-            <version>3.12.30-SNAPSHOT</version>
+            <version>3.12.42-SNAPSHOT</version>
         </dependency>
     </dependencies>