Skip to content

KAFKA-3318: clean up consumer logging and error messages#1036

Closed
hachikuji wants to merge 5 commits into
apache:trunkfrom
hachikuji:KAFKA-3318
Closed

KAFKA-3318: clean up consumer logging and error messages#1036
hachikuji wants to merge 5 commits into
apache:trunkfrom
hachikuji:KAFKA-3318

Conversation

@hachikuji
Copy link
Copy Markdown
Contributor

No description provided.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Typo "poll() by with max.poll.records"?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ack.

@SinghAsDev
Copy link
Copy Markdown
Contributor

Minor comment, otherwise LGTM!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Do we really need two log statements so near to each other? I guess the second one also includes the co-ordinator id. Would it be too confusing to include it in the previous log statement?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The coordinator id ends up being a really big negative integer, but if we used host:port in the log message then maybe it wouldn't be too bad? We'd probably want to make the same change in the other messages as well.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Interesting. Which is more useful host:port or id? If the latter, let's just leave as is. Otherwise, then changing it here and other places sounds good.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Usually the host:port is more helpful when debugging, and it's kind of a pain to do the reverse mapping from id to host in my head. The only time the id is helpful is when looking at NetworkClient issues.

@ijuma
Copy link
Copy Markdown
Member

ijuma commented Mar 9, 2016

Thanks for this @hachikuji, very important. :) I left a few comments, looks good otherwise.

@hachikuji
Copy link
Copy Markdown
Contributor Author

@ijuma Made some more improvements. In particular, I wanted to ensure that the groupId was always provided since otherwise it's difficult to follow logs which contain multiple consumer instances. I also tried to address the review comments.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Should we change the toString of Node to be more logging friendly?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It currently looks like "Node(id, host, port)," which doesn't seem too bad to me. What do you think?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

When I suggested it, I thought we could do a bit better, maybe something like (id: 5, www.example.com:9123), but maybe that's actually worse.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I was mostly trying to get rid of the word Node because it's a bit redundant when you look at the log messages.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Initially I didn't use Node's toString() at all. I just filled in "{}:{}" with the host and port, but that got a little annoying after a couple times. But maybe it's actually better?

@ijuma
Copy link
Copy Markdown
Member

ijuma commented Mar 9, 2016

@hachikuji I did another pass. That last commit changed more than the previous ones! I think it's looking pretty good now. I had a small number of comments/questions.

@gwenshap
Copy link
Copy Markdown
Contributor

LGTM

@asfgit asfgit closed this in e403b3c Mar 10, 2016
efeg added a commit to efeg/kafka that referenced this pull request Jan 29, 2020
mumrah pushed a commit to mumrah/kafka that referenced this pull request Aug 14, 2024
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.

4 participants