Follow-up to PR #12464#12541
Conversation
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
|
|
||
| // Versions -- knobs that control 5s timeout | ||
| init( VERSIONS_PER_SECOND, 1e6 ); | ||
| init( VERSIONS_PER_SECOND, clientKnobs->VERSIONS_PER_SECOND ); |
There was a problem hiding this comment.
I think you misunderstood my question. It was not about this knob (VERSIONS_PER_SECOND) but the knob below it (which you modified in PR #12464). I was trying to ask this: you set that server knob's value to the corresponding client knob's value in commit b2633d2 in that PR, but in commit 906789b (in that PR) you modified that to be assigned randomly. Is that an intentional change?
There was a problem hiding this comment.
Please revert this change to VERSIONS_PER_SECOND. Thanks!
There was a problem hiding this comment.
I see, you seem to be referring to MAX_READ_TRANSACTION_LIFE_VERSIONS. That is not present in client knobs. Client only uses MAX_WRITE_TRANSACTION_LIFE_VERSIONS.
I will revert this change then.
Relatedly, I wonder why github did not show the right line. I see this:
So R35 seems correct and is pointing to VERSIONS_PER_SECOND. Maybe you put in a comment on an older version of the PR and github got confused.
There was a problem hiding this comment.
you set that server knob's value to the corresponding client knob's value in commit b2633d2 in that PR, but in commit 906789b (in that PR) you modified that to be assigned randomly.
b2633d2 changes ServerKnobs::MAX_WRITE_TRANSACTION_LIFE_VERSIONS to use clientKnobs::MAX_WRITE_TRANSACTION_LIFE_VERSIONS.
906789b changes MAX_READ_TRANSACTION_LIFE_VERSIONS to just use the new function name (getSimulatedTxnTimeoutSeconds instead of randomTxnTimeoutSeconds).
There was a problem hiding this comment.
I caused the confusion, apologies! I follow your changes now, thanks!
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
* remove server FASTRESTORE_ATOMICOP_WEIGHT * address other feedback * fix spacing * revert VERSIONS_PER_SECOND change
* remove server FASTRESTORE_ATOMICOP_WEIGHT * address other feedback * fix spacing * revert VERSIONS_PER_SECOND change
Description
This PR addresses all remaining feedback in #12464.
Changes:
Testing
Ran 200K:
Because of some joshua infra issue, this failed early. I can not see any failures from j tail output.
Running two 100Ks again (in progress):
The first run was 100K/100K pass. The second run was 99999/100K pass, 1 failure was: tests/fast/RandomUnitTests.toml
Sev40 is:
This test was recently added and I don't think it has anything to do with this PR. I'll start an internal thread about this.
Running another 100K after latest commit:
20251107-230734-praza-pr12464-followup-0c1e-5fafb2e54be0db24 compressed=True data_size=37437746 duration=5761019 ended=100000 fail=1 fail_fast=10 max_runs=100000 pass=99999 priority=100 remaining=0 runtime=0:56:43 sanity=False started=100000 stopped=20251108-000417 submitted=20251107-230734 timeout=5400 username=praza-pr12464-followup-0c1e6053e35cf6aea0b5424f01692aa7aba1468b
It is a non-functional change but will wait for pass before merging. Update: the failure does not look related to this PR.
Code-Reviewer Section
The general pull request guidelines can be found here.
Please check each of the following things and check all boxes before accepting a PR.
For Release-Branches
If this PR is made against a release-branch, please also check the following:
release-branchormainif this is the youngest branch)