-
Notifications
You must be signed in to change notification settings - Fork 10
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
UploadDocs failure should throw an Exception #87
Comments
@nginthfs is there any retry for that? |
I don't believe that there is. I think what happens now is that the doc gets thrown away and the indexing benchmark continues on. |
I know sometimes there could be bad fields in some docs that caused indexing failure, tho that one is not 404, probably 500 i think |
Yeah 500s should probably also fail the task, so we can identify the issue and fix it. The only thing that shouldn't fail the task IMO are timeouts or 429s, which should be retried (although retries are a bigger issue than this, maybe we could add that on as a follow up issue). |
I think bad fields (or extra fields) cause 400 (bad request). 404 is
special case of non existent collection and can be dealt with as a special
case.
…On Tue, 9 Jan, 2024, 11:36 pm Nick Ginther, ***@***.***> wrote:
Yeah 500s should probably also fail the task, so we can identify the issue
and fix it. The only thing that shouldn't fail the task IMO are timeouts or
429s, which should be retried (although retries are a bigger issue than
this, maybe we could add that on as a follow up issue).
—
Reply to this email directly, view it on GitHub
<#87 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABDCR5A7YC4VAAIAWMY4JITYNWBLTAVCNFSM6AAAAABBR5L5CGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTGU2DEMZTGI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Currently, when UploadDocs fails, we just log the error and go on with the test. This can throw off test results when comparing among Solr setups, since both setups may end up with more/less docs in their collections. To fix this, I think UploadDocs should throw an Exception if it receives a non-200 status code, or at least "fatal" status codes such as 404. Then, callers should handle this by ending the test preemptively (we may not have to change the callers' code, not sure!).
See:
solr-bench/src/main/java/org/apache/solr/benchmarks/indexing/UploadDocs.java
Line 102 in f8e2567
The text was updated successfully, but these errors were encountered: