* Don't test requests that don't initialize properly
Some request objects don't initialize their members
properly when being constructed using the default
constructor. This makes valgrind unhappy. Don't test
these endpoints for now.
* fixed code formatting
The ClientDBInfo's comparison is through an internal UID and shrinkProxyList()
can change proxies inside ClientDBInfo. Since the UID is not changed by that
function, subsequent set can be unintentionally skipped.
This was not a big issue before. However, VV introduces a change that the
client side compares the returned proxy ID with its known set of GRV proxies
and will retry GRV if the returned proxy ID is not in the set. Due the above
bug, GRV returned by a proxy is not within the client set, and results in
indefinite retrying GRVs.
There is a bug in how a log router handles streaming read:
* Log router has a `logRouterPeekStream` actor A running.
* Remote tlog detects some problem and starts another streaming connection (maybe just reuse the connection?)
* Log router now has a new `logRouterPeekStream` actor B running.
* B runs and found that popped version > reqBegin, so `LogRouterPeekPopped` . This is because A is still running and changed the popped version.
* A ends with `TLogPeekStreamEnd operation_obsolete`
* B become stuck at `wait(req.reply.onReady() && store(reply.rep, future)`, because the future was sent `Never()`.
As a result, the remote tlog can no longer retrieve data from this log router.
Fix by killing the `logRouterPeekStream` B.
* Re-throw operation_cancelled
There's a few places in fdbcli where we don't rethrow operation
cancelled but wait on a future. It's very unusual that you don't want to
rethrow operation_cancelled.
* Update ASSERT
It's possible to get error_code_broken_promise here if the network has
already shutdown.
This was not set and can cause infinite loop in simulation where the client
calls getConsistentReadVersion(), in which we do "continue" for stale GRV reply
and retry. Then this repeats forever.
Encoding methods used:
- Tag localities: Run length encoding
- Tag ids: Compact representation
- Commit versions: delta encoding.
If "n" is the number of entries in the version vector, with the tags
spread over "m" data centers, these techniques will reduce the number
of bytes to represent the version vector from "(11 * n)" bytes to
"(3 * m + 2 * n)" / "(3 * m + 3 * n)" bytes (depending on the max tag
id value, and ignoring some constants) in the best case.
Chaoguang Lin