-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LuceneIndexMaintenanceTest sometimes take many minutes #2842
Comments
ScottDugas
added a commit
to ScottDugas/fdb-record-layer
that referenced
this issue
Jul 23, 2024
To help investigate FoundationDB#2842 I'm hoping that something will timeout that isn't the test, and that will give us a good starting point.
After adding the timeout, it seems clear that one test will get a timeout, and then all remaining tests will either get an asyncToSync timeout at the first store open or timeout overall. |
ScottDugas
added a commit
to ScottDugas/fdb-record-layer
that referenced
this issue
Jul 31, 2024
Sleeping for a second between tests didn't seem to make the tests behave well, trying to slow down the document generation used in the most expensive tests. Hopefully this will make FoundationDB#2842 no longer a problem.
ohadzeliger
pushed a commit
that referenced
this issue
Jul 31, 2024
Sleeping for a second between tests didn't seem to make the tests behave well, trying to slow down the document generation used in the most expensive tests. Hopefully this will make #2842 no longer a problem.
ScottDugas
added a commit
to ScottDugas/fdb-record-layer
that referenced
this issue
Aug 1, 2024
This is an attempt to investigate Issue FoundationDB#2842 in a remote environment. The theory is that the cluster is in a state where it is rejecting all transactions, but the hope is that it is in a state where status works, and will tell us what is wrong. This is resiliant to not having `fdbcli` on your path or if you are using `fdb-environment.properties` instead of the default cluster file, but it will just print errors that it could not get the status.
ohadzeliger
pushed a commit
that referenced
this issue
Aug 1, 2024
This is an attempt to investigate Issue #2842 in a remote environment. The theory is that the cluster is in a state where it is rejecting all transactions, but the hope is that it is in a state where status works, and will tell us what is wrong. This is resiliant to not having `fdbcli` on your path or if you are using `fdb-environment.properties` instead of the default cluster file, but it will just print errors that it could not get the status.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've seen test runs where it takes many minutes. Often on
manyDocument
ormanyDocumentSlow
orconcurrentStoreTest
The text was updated successfully, but these errors were encountered: