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-2978: consumer stops fetching when consumed and fetch positions get out of sync #666

Closed
wants to merge 3 commits into from

Conversation

hachikuji
Copy link
Contributor

No description provided.

@hachikuji
Copy link
Contributor Author

@guozhangwang Ping for review. I replaced the consumed/fetched variables with a single position. This seems to work fine with pre-fetching and it simplifies the code. Have a look and let me know if I missed something.

@mixalturek
Copy link

I was a little confused with boxing/unboxing of long/Long and ==/equals, but the updates look ok.

@ijuma
Copy link
Contributor

ijuma commented Dec 11, 2015

Michal tested this branch and it fixes the issue he was seeing. Is there a way we can write a test (system or otherwise) that captures the problem?

@hachikuji
Copy link
Contributor Author

@ijuma I was thinking about that. I think the main reason we didn't catch it in our system tests is that we weren't looking for it. In our current tests, we check after every rebalance that at least some messages are consumed, but we should strengthen that to assert that some messages from each partition are consumed. If it seems reasonable, I'll open a separate JIRA for this.

@ijuma
Copy link
Contributor

ijuma commented Dec 11, 2015

That sounds good to me @hachikuji

fetch.put(partition, new FetchRequest.PartitionData(fetched, this.fetchSize));
long position = this.subscriptions.position(partition);
fetch.put(partition, new FetchRequest.PartitionData(position, this.fetchSize));
log.debug("Added fetch request for partition {} at offset {}", partition, position);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we might want to consider dropping some of these log.debugs to log.trace. Some of the logs in error conditions make sense at debug, but logging every fetch request and response at debug might make changing from info to debug a bit overwhelming.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Trace level is fine with me.

@guozhangwang
Copy link
Contributor

LGTM. @hachikuji do you want to change the logging level before merging. Also a good idea to strengthen system tests for this case.

@hachikuji
Copy link
Contributor Author

@guozhangwang I reduced the logging to trace level along the "happy paths." The build failure looks like an instance of KAFKA-2442. I can make the changes to the system tests here, but would that make cherry-picking more difficult for the 0.9.0 branch?

@ijuma
Copy link
Contributor

ijuma commented Dec 14, 2015

IMO system tests could be done as a separate JIRA since this branch was validated by the reporter of this issue.

@ijuma
Copy link
Contributor

ijuma commented Dec 14, 2015

@hachikuji did you run the system tests on this branch? If not, maybe a good idea to do it?

@hachikuji
Copy link
Contributor Author

@ijuma I haven't run all system tests, but I've run consumer_test.py a couple times without problems.

@hachikuji
Copy link
Contributor Author

FYI: I created KAFKA-2989 to improve the system tests.

@asfgit asfgit closed this in e08b922 Dec 14, 2015
asfgit pushed a commit that referenced this pull request Dec 14, 2015
… get out of sync

Author: Jason Gustafson <jason@confluent.io>

Reviewers: Michal Turek, Ismael Juma, Guozhang Wang

Closes #666 from hachikuji/KAFKA-2978

(cherry picked from commit e08b922)
Signed-off-by: Guozhang Wang <wangguoz@gmail.com>
@guozhangwang
Copy link
Contributor

Merged to trunk and 0.9.0.

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