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

(#127) Degrading retry DNS resolve. Needs tests #133

Closed
wants to merge 5 commits into from

Conversation

bigtoast
Copy link
Contributor

Hi Friends,

I've only tested this manually. I still need to grok how the snapshot testing infrastructure works and then figure out how to shoehorn some dns resolve failures into a test. While I do that, I figure I might as well send this for at least a code review because I moved some stuff around and my approach should be reviewed as well.

I moved adding ips to pending out of the Client::resolve function and into the block defining handle. All ips are added to pending along with a counter for how many times the client has been asked to resolve the ip. If it is the first attempt or an attempt that is a power of 2, an actual dns call will be made. If an ip is resolved it will be removed from pending. This will indirectly give the increasing retry timeout suggested in the previous comment. e.g. 2, 4, 8, 16 seconds.

Let me know if any of this looks weird. I am still getting used to borrowing/clone etc. and I have discovered doing simple stuff with numbers in rust makes me want to stab hot pokers into my eyeballs. I think I just need to get used to it.

Copy link
Owner

@imsnif imsnif left a comment

Choose a reason for hiding this comment

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

This looks great. I like the approach and left some nitpicks in the code.

Other than that, let's as you say add some tests for this.

I'd be happy to go over the snapshotting mechanism with you, but first could you tell me what part is unclear? (unless of course it's the whole thing :) )

Pre-pull request checklist:
- Run tests: `cargo test`
- Check the formatting: `cargo fmt -- --check`
- Run linter: `cargo clippy --all-targets --all-features -- -D warnings`
Copy link
Owner

Choose a reason for hiding this comment

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

Thank you very much for your documentation efforts! I think other contributors will find these very helpful.

let ips = ips
.into_iter()
.filter(|ip| {
let mut pending = pending.lock().unwrap().clone();
Copy link
Owner

Choose a reason for hiding this comment

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

Do you think we can move the mutex lock outside of the loop? Otherwise it'll constantly be locking/unlocking for every ip in the list. Or is there a consideration here I'm not seeing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea. Will do.

@bigtoast
Copy link
Contributor Author

There's no real confusion (yet) regarding snapshotting. I just need to spend some time looking at it which I haven't really done so far. Since you're okay with the approach above, I'll dig into the testing.

Thanks for the review and comments.

@imsnif
Copy link
Owner

imsnif commented Sep 13, 2020

Hey, this was closed by mistake and I don't seem to be able to re-open it. Please feel free to re-open or make another PR with this if you wish. My apologies!

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

Successfully merging this pull request may close these issues.

None yet

2 participants