Skip to content
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

Adds stats counter for failed indexing requests #13130

Closed

Conversation

andrestc
Copy link
Contributor

#8938 - This adds a field index_failed to _stats showing how many index requests failed.

refactor

adds tests

refactor
@andrestc andrestc changed the title Adds counter for failed indexing requests Adds stats counter for failed indexing requests Aug 26, 2015
@clintongormley clintongormley added >enhancement review :Data Management/Stats Statistics tracking and retrieval APIs labels Aug 27, 2015
@@ -155,6 +161,7 @@ public void readFrom(StreamInput in) throws IOException {
indexCount = in.readVLong();
indexTimeInMillis = in.readVLong();
indexCurrent = in.readVLong();
indexFailedCount = in.readVLong();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I imagine we'll need the if (version.onOrAfter(Version.V_2_1_0)) dance around these reads and writes here. We didn't need it in 2.0 because we don't have multi-version compatibility but this will probably go to 2.1 and that'll have to be compatible with 2.0.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

er - I think it goes like if (in.version().onOrAfter(Version.V_2_1_0)) or something like that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be wrapping my change only, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup - just that read and write you inserted. Without it this isn't compatible with 2.0 servers. Usually people only run mixed version clusters during a rolling upgrade but its nice if everything continues to work then.

@nik9000
Copy link
Member

nik9000 commented Aug 27, 2015

Looks pretty good. I left some comments about the test and compatibility with multiple node versions which I assume is a thing because this is (rightly) targeting master and not the 2.0 branch.

@nik9000 nik9000 added the v2.1.0 label Aug 27, 2015
@nik9000 nik9000 self-assigned this Aug 27, 2015
@andrestc
Copy link
Contributor Author

@nik9000 I made some questions regarding some of your comments (mostly because im a new contributor so I don't know much about the codebase).
Will update my PR once I have the answers.

Thanks for the review.

@nik9000
Copy link
Member

nik9000 commented Aug 27, 2015

Will update my PR once I have the answers.

I think I just answered actually. Good timing!

The best thing is to send a new commit that changes the changes and squash later (or not). Its easier to review that way.

@andrestc
Copy link
Contributor Author

@nik9000 Just pushed it!
Thanks.

@nik9000
Copy link
Member

nik9000 commented Aug 27, 2015

Looks good to me. I'd love to get a review from someone else just to be 100% sure. If someone doesn't show up in the next few hours I'll go hunting.

@jasontedor
Copy link
Member

@andrestc Do you think that you can add this to the cat API as well?

@andrestc
Copy link
Contributor Author

@jasontedor Sure, ill give it a shot and ask for help if i get stuck.

@jasontedor
Copy link
Member

@andrestc Sounds good, thank you!

@andrestc
Copy link
Contributor Author

@jasontedor There it is!

@nik9000
Copy link
Member

nik9000 commented Aug 31, 2015

Thanks for remembering the _cat api, @jasontedor. I forgot it often.

@nik9000
Copy link
Member

nik9000 commented Aug 31, 2015

Ok! I found another fun thing to test. You can test the backwards compatibility by writing an ESBackcompatTestCase. It looks like IndexingStats doesn't have one by NodeStats does. So you could use it as a starting point. That'd verify the need for that Version check.

@andrestc, are you up for it? You've been a great sport so far! You'll have to look into testing.asciidoc for instructions on running these. The python script that fetches the index is out of date on your branch so you'd need to run it on the master branch and switch back to your branch.

@andrestc
Copy link
Contributor Author

@nik9000 I'll give it a shot during the week, sure!
Will get back to you if i get stuck.
Thanks!

@andrestc
Copy link
Contributor Author

andrestc commented Sep 3, 2015

@nik9000 I'm having some problems to run the backwards tests.
First, On what version should i run against?
I followed the Testing.
I've tried it with 1.7.0 by doing the following:
After downloading, etc etc. I ran:

python ev-tools/create_bwc_index.py 1.7.0

When i run:

mvn test -Dtests.filter="@backwards" -Dtests.bwc.version=1.7.0 -Dtests.security.manager=false

Its fails and tells me there were no executed tests(i tried with "@Backwards", too). So i guess the problem is with the filter on mvn test.

Any ideas?

@dakrone
Copy link
Member

dakrone commented Sep 9, 2015

This LGTM, I do agree with @nik9000 though that it would be nice to have BWC tests for IndexingStats

@nik9000 it looks like you opened an issue to fix the BWC test infrastructure, do you want to wait on this until that is fixed, or do the testing in a subsequent issue?

@nik9000
Copy link
Member

nik9000 commented Sep 9, 2015

@nik9000 it looks like you opened an issue to fix the BWC test infrastructure, do you want to wait on this until that is fixed, or do the testing in a subsequent issue?

Either one is fine with me. @andrestc, if you are ok with me merging this as is I'll create a followup issue for the the backwards compatibility test. I don't want to block this pr forever just because we've broken part of our infrastructure.

@andrestc
Copy link
Contributor Author

andrestc commented Sep 9, 2015

@nik9000 I'm definitely okay. As soon as the backwards infrastructure is okay I can submit a PR with this tests.

@nik9000
Copy link
Member

nik9000 commented Sep 9, 2015

@nik9000 I'm definitely okay. As soon as the backwards infrastructure is okay I can submit a PR with this tests.

Cool. I'll merge it soon-ish then. I have 5 tabs worth of code reviews and merges to do when I stop concentrating on fixing the backwards compatibility tests.

@nik9000
Copy link
Member

nik9000 commented Sep 10, 2015

OK! I picked this up to merge it this morning. I squashed it and reran the tests. One of the rest tests was failing so I'll ship a commit along with the merge that fixes it. It didn't merge 100% clean with master but the only conflict was obvious to resolve. I'll be rerunning the tests with the work staged on master locally and when all that passes I'll push to master. After that I'll backport to the 2.x branch which will eventually be used to form the 2.1 release.

@nik9000
Copy link
Member

nik9000 commented Sep 10, 2015

Merged to master: 3839d15

@nik9000
Copy link
Member

nik9000 commented Sep 10, 2015

And merged to 2.x: 1e347c3

This should show up in 2.1.0 whenever that is released.

@nik9000
Copy link
Member

nik9000 commented Sep 10, 2015

Thanks so much for this @andrestc. Thanks for working through all the changes. I'm sorry you were the first person to hit the backwards compatibility tests being busted (#13425). We'll get those fixed up as soon as we can!

Thanks again!

@andrestc
Copy link
Contributor Author

@nik9000 Np! Thanks for the review!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants