Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Type||Name||Latest commit message||Commit time|
|Failed to load latest commit information.|
This app is built to check if transactions are dropped, executed out of order, or run more than once on individual partitions. It can also be used as a long running test because data does not grow indefinitely. The following is a list of features this app has: - Creates a set of logical clients, each with a CID value. - Each client gets a thread that performs synchronous operations against a running VoltDB server. - Depending on the 10-mod of the CID, each thread will run SP, MP or hybrid transactions against replication or partitioned tables. - All transactions run by the logical clients do the same work. - They add a new row id (RID) that's supplied by the client and ensure it's monotonically increasing. - They add a new counter (CNT) which is incremented from within the txn. - They select all data with their CID and perform a "Cheesy Checksum", storing the result in the table. - They read data from secondary tables which are updated by adhoc queries. - A thread runs adhoc DML that changes both replicated and partitioned tables. The most recent entry is read and re-stored by the main procedures. This means the order AdHoc and regular procs run in is critical. - Another thread calls non-existent/dropped stored procedures. - Secondary tables that get loaded with dummy data to ensure snapshots, rejoins and DR syncs are non-trivial. - MP and SP read operations that validate data. - An export table in the DDL with inserts that shadow inserts to persistent tables - The app also starts 2 Threads (MP & SP) to do Load*Table transactions. Load*Table transaction threads launch CopyAndDelete tasks which periodically copies data from Load*Table assigned table to diff tables to sprinkle in other transactions. If a transaction is run out of order, missing or run twice, these mechanisms should fail. This failure should be detected by: - Validating data in the transaction. - Validating data at the client logic. - The determinism checks built into VoltDB. Procedures returning GRACEFUL FAILURE or USER_ABORT are treated as terminal failures. Other exceptions/errors may be logged and then the client will continue if possible. Some threads like the adhoc, read, or loader threads may just stop on failure, leaving the primary write transactions still running. Valid total simultaneous thread counts for clients is 127. To run two clients at once, set an offset using the command line arguments so two clients don't claim the same range of [0,127].