TVU CLI parameters

The following sections list the Transaction Validator Utility (TVU) CLI parameters. You can use these parameters to perform various actions on transactions present in your database.

Path to the node’s base directory for reading configuration directly from a node. If this option is not supplied, then the current directory is taken as the node’s base directory.

If this option is specified, then CorDapps are also loaded from the supplied base-directory/cordapps directory and transaction deserialization is enabled by default.

Example:

java -jar transaction-validator.jar -b /corda/cordapp-template-java/build/nodes/PartyA

The full user-defined class name used for transaction processing. The class must implement (SignedTransactionWithTimestamp) -> Unit and should be placed under the node’s drivers directory: /drivers. The node’s base directory is taken as specified by the configuration in -b or --base-directory parameter.

If this option is not provided, then the utility proceeds with default transaction validation which includes transaction verification and deserialization.

Example:

java -jar transaction-validator.jar -c net.corda.tvu.SampleApp

A directory where the utility stores information about transactions it failed to process. The data files describing all failed transactions are captured in a .zip file whose name is the timestamp of when the file was generated. If not specified, the current working directory is assumed.

Path to the node’s configuration file for reading configuration directly from a node. Can have the -b or --base-directory option. If this parameter is not supplied, the default is node.conf.

Example:

java -jar transaction-validator.jar -b /corda/cordapp-template-java/build/nodes/PartyA -f /corda/cordapp-template-java/build/nodes/PartyA/some-other-node.conf

Provides the information about and the list of all the TVU CLI options.

File path to the location containing the IDs of the transactions to be reprocessed. The reverification does not happen if this option is absent. The file containing IDs of the transactions to be reprocessed can be either:

  • A text file containing newline-separated list of transaction IDs.
  • A .zip file that is created automatically when the TVU encounters errors. This error .zip file stores erroneous transactions’ raw data.

A file path where the current progress will be stored and the last progress can be loaded from. If the given file is empty, then the utility starts processing transactions from the beginning.

If this parameter is not provided, then progress is logged on-screen and the utility starts processing transactions starting with the earliest transaction in the database as per transaction time.

The transaction time from which the utility resumes transaction verification. The provided transaction time is compared against transaction recorded time. The utility loads transactions which have a transaction timestamp greater than or equal to the provided time.

If this parameter is not provided, then the utility starts processing transactions from the earliest transaction in the database as per transaction time or loads progress from file if the -f option is specified.

You can create a new time instant by providing a UTC timestamp in format: 2007-12-03T10:15:30.00Z. The string must represent a valid instant in UTC and is parsed using DateTimeFormatter.ISO_INSTANT.

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.