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

extensions: add retry host predicate for attempted hosts #4452

Merged
merged 3 commits into from
Sep 23, 2018

Conversation

snowp
Copy link
Contributor

@snowp snowp commented Sep 18, 2018

Adds a simple RetryHostPredicate that keeps track of hosts that have
already been attempted, triggering a new host to be selected if an
already attempted host is selected.

Signed-off-by: Snow Pettersen snowp@squareup.com

Risk Level: Low
Testing: Unit test
Docs Changes: n/a
Release Notes: n/a
Part of #3958

Adds a simple RetryHostPredicate that keeps track of hosts that have
already been attempted, triggering a new host to be selected if an
already attempted host is selected.

Signed-off-by: Snow Pettersen <snowp@squareup.com>
class OtherHostsRetryPredicateFactory : public Upstream::RetryHostPredicateFactory {
public:
void createHostPredicate(Upstream::RetryHostPredicateFactoryCallbacks& callbacks,
const ProtobufWkt::Struct&) override {
Copy link
Member

Choose a reason for hiding this comment

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

@htuch I think I was too late to point out this in #4385, we should avoid leaking Struct to extension interfaces? This is similar to #3155, and given we are already facing some config performance issue so it makes sense.

Copy link
Member

Choose a reason for hiding this comment

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

Let's continue this discussion in #4475. We do want to move in this direction, but we want to maintain a consistent and unsurprising API surface for extensions.

Copy link
Member

Choose a reason for hiding this comment

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

@snowp is this the right PR to followup on #4475 tactical changes or should we review as is and you'll do that in a followup?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it makes sense to do in a follow up, that way I can do both extensions at the same time without cluttering this PR

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, considering #4385 has still not been reviewed (and this introduces the other Struct usage) I think I'll just do it in each PR separately

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Turns out it's more elaborate than I thought - I'll update this PR to use MessagePtr instead of Struct and then follow up with another PR setting up a base factory to convert that into a config proto. This PR isn't relying on parsing a config proto, so I think it can be merged without having all that set up

Sorry for being so indecisive!

@htuch htuch self-assigned this Sep 20, 2018
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

LGM modulo question of Struct.

Signed-off-by: Snow Pettersen <snowp@squareup.com>
htuch
htuch previously approved these changes Sep 21, 2018
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

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

Thanks!

Signed-off-by: Snow Pettersen <snowp@squareup.com>
@htuch htuch merged commit 4368b48 into envoyproxy:master Sep 23, 2018
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

Super cool!

}

private:
std::unordered_set<std::string> attempted_hosts_;
Copy link
Member

Choose a reason for hiding this comment

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

@snowp I'm not sure of my comment came through here or not: I suspect that a vector or fixed size array initialized to the number of max retries would end up being faster here and use less memory given the generally tiny number of allowed retries. Something to think about / TODO in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That sounds like a good idea. I think the only complication is having to plumb through the max retries count, but since other implementations might also find it useful for similar use cases it should probably be part of the factory interface.

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

4 participants