Right now this only allows one server address being excluded. This is useful
when the database is unavailable but we want the recruitment to skip some
particular processes.
Manually tested the concept works with a loopback cluster.
* Introducing default transaction options for report_conflicting_keys and used_during_commit_protection_disable, set the latter option always in Java bindings
* Reformatting TransactionIntegrationTest.java
* Update description of transaction_report_conflicting_keys option
* Remove dependency between mock and real database implementation in RangeQueryTest.java
* Update generated.go after changing desciption of an option
* Small improvements of the TransactionIntegrationTest code
Description
Two major changes proposed are:
I)
Used following setup for testing:
1. Run `fdbserver` locally.
2. Run a mock python based HTTP server (encryption endpoints not implemented)
Expectation was RESTClient code should go in loop trying to establish connection
to the desired encryption endpoint. However, observation was the code loops for
one cycle and followup cycle SEGV while printing a log using RESTUrl object which
is obtained as a 'pointer' from the caller. Update the code to use RESTUrl object
instead of the pointer.
II) In above setup, KMSConnector would throw 'encrypt_key_fetch_failed' error
which wasn't handled by EKProxy, hence, causing the service to terminate. Add
code to re-throw the error to the caller.
Testing
A script, rocksdb_logtool.py, is available to upload/download generated
XML/JSON log files when test harness 2 detects that the test is failed,
and the script detects that the test is using RocksDB.
To upload, no actions is needed, using the regular
```
joshua start --tarball correctness.tgz
```
The build system will automatically pack the rocksdb_logtool.py into the
tarball and test harness 2 will call the script if it thinks the test is
failed.
To download, simply provide the ensemble id and test uid, e.g.
```
python3 rocksdb_logtool.py download --ensemble-id
20230222-204240-xiaogesu-cb6ea277a898f134 --test-uid
ab6fb792-088f-49d6-92d2-43bc4fb81668
```
Note the test UID can be retrieved by
```
joshua tail ensemble_id
```
output, it is in the field `TestUID` in <Test> element of test harness 2
generated XML.
For convenience, it is possible to do a
```
python3 rocksdb_logtool.py list --ensemble-id ensemble-id
```
to generate all possible download commands for failed tests. However,
the list subcommand will *NOT* verify if the test failure is coming from
RocksDB, i.e. other test failues may be included and it is the caller's
responsibility to verify. If the test is not RocksDB related, the
download would fail as nothing is uploaded.
A.J. Beamon