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

KAFKA-6101 Reconnecting to broker does not exponentially backoff #4108

Closed
wants to merge 7 commits into from
Closed

Conversation

tedyu
Copy link
Contributor

@tedyu tedyu commented Oct 21, 2017

For reconnection, share the nodeState if one exists.
Only update its state and lastConnectAttemptMs.

@tedyu
Copy link
Contributor Author

tedyu commented Oct 21, 2017

retest this please

@ijuma
Copy link
Contributor

ijuma commented Oct 21, 2017

Thanks for the PR. Can we please add a test?

@tedyu
Copy link
Contributor Author

tedyu commented Oct 21, 2017

I ran thru NetworkClientTest but the tests didn't exercise the code path I modified.

Suggestion on how to emulate the scenario is appreciated.

@tedyu
Copy link
Contributor Author

tedyu commented Oct 21, 2017

None of the clients tests references ClusterConnectionStates.
I can add a counter which is incremented in the if block below:

    public void connecting(String id, long now) {
        if (nodeState.containsKey(id)) {

Some test can assert that the counter is greater than one.

But ClusterConnectionStates is not public.

@tedyu
Copy link
Contributor Author

tedyu commented Oct 22, 2017

KafkaProducer doesn't expose getter for Sender.
Still looking for way(s) to access ClusterConnectionStates from test.

@@ -28,6 +30,7 @@
*
*/
final class ClusterConnectionStates {
private static final Logger log = LoggerFactory.getLogger(ClusterConnectionStates.class);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a specific reason for adding this in? I can't find any usages of the logger ..

@tedyu
Copy link
Contributor Author

tedyu commented Oct 22, 2017

Ran the following using Java 8 which passed:

./gradlew -PscalaVersion=2.12 -Dtest.single=ResetIntegrationTest streams:test

@soenkeliebau
Copy link
Contributor

Hi @tedyu, you are indeed right, there are no tests covering this code, however I'd argue that there should be. I've created some test cases in a pull request to cover the basic workings of this class as I understand it. I've left out a test for the code you fixed for now, as it'd fail anyway.
I've also created a pull request against your fork with the skeleton of the test class, so you should be able to add your test cases in there and everything should merge later on, regardless of the order it may be applied in.

@tedyu
Copy link
Contributor Author

tedyu commented Oct 22, 2017

Thanks, @soenkeliebau

Please give Sönke credit since the test came from him.

@soenkeliebau
Copy link
Contributor

Hi @tedyu - I may have phrased my last comment badly, the test I referenced does not test proper backoff behavior but only the maximum backoff value, to test your code we need a test case that checks for the backoff to be within the proper range for a few reconnect attempts. I've sent you a new pull request with a proposal of how a test case like that could look.

Rewrote test case to check proper backoff handling (Sönke).
@tedyu
Copy link
Contributor Author

tedyu commented Oct 23, 2017

retest this please

@ijuma
Copy link
Contributor

ijuma commented Oct 23, 2017

@tedyu, can you please rebase against trunk? Thanks.

@tedyu
Copy link
Contributor Author

tedyu commented Oct 23, 2017

Let me open a new PR.

@tedyu tedyu closed this Oct 23, 2017
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.

3 participants