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-5506: Fix NPE in OffsetFetchRequest.toString #3420

Closed

Conversation

ijuma
Copy link
Contributor

@ijuma ijuma commented Jun 23, 2017

Also include a number of improvements in NetworkClient's logging:

  • Include correlation id in a number of log statements
  • Avoid eager toString call in parameter passed to log.debug
  • Use node.toString instead of passing a subset of fields to the
    logger
  • Use requestBuilder instead of clientRequest in one of the log
    statements

@ijuma
Copy link
Contributor Author

ijuma commented Jun 23, 2017

Review by @dguy.

@@ -371,8 +371,7 @@ private void doSend(ClientRequest clientRequest, boolean isInternalRequest, long
} catch (UnsupportedVersionException e) {
// If the version is not supported, skip sending the request over the wire.
// Instead, simply add it to the local queue of aborted requests.
log.debug("Version mismatch when attempting to send {} to {}",
clientRequest.toString(), clientRequest.destination(), e);
log.debug("Version mismatch when attempting to send {} to {}", clientRequest, clientRequest.destination(), e);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's a bit odd that we output the full clientRequest and one of its fields separately. We could potentially remove the latter or replace the former with a subset of fields. Either way, we should not be calling toString.

Copy link
Contributor

Choose a reason for hiding this comment

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

It does seem a bit odd as ClientRequest#toString has the destination. Should we just remove clientRequest.destination() as it isn't really adding any additional value?

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 that's fair. I was a bit undecided between doing that and changing the first parameter to be more like the other logging statements in the class where we don't log the full client request. Do you have a preference?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd go for being consistent with the other logging statements

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I replaced clientRequest with the request builder. That would have the information missing from UnsupportedVersionException (the latter would have the api key and version that was requested).

Copy link
Contributor

@dguy dguy left a comment

Choose a reason for hiding this comment

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

I've left one minor comment that I'll leave to you to decide if you want to change or leave as is. Otherwise LGTM

@@ -371,8 +371,7 @@ private void doSend(ClientRequest clientRequest, boolean isInternalRequest, long
} catch (UnsupportedVersionException e) {
// If the version is not supported, skip sending the request over the wire.
// Instead, simply add it to the local queue of aborted requests.
log.debug("Version mismatch when attempting to send {} to {}",
clientRequest.toString(), clientRequest.destination(), e);
log.debug("Version mismatch when attempting to send {} to {}", clientRequest, clientRequest.destination(), e);
Copy link
Contributor

Choose a reason for hiding this comment

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

It does seem a bit odd as ClientRequest#toString has the destination. Should we just remove clientRequest.destination() as it isn't really adding any additional value?

@asfgit
Copy link

asfgit commented Jun 23, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/5645/
Test PASSed (JDK 8 and Scala 2.12).

@asfgit
Copy link

asfgit commented Jun 23, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/5659/
Test FAILed (JDK 7 and Scala 2.11).

@ijuma
Copy link
Contributor Author

ijuma commented Jun 23, 2017

@hachikuji, maybe you can take a look in this small PR. The important change is that we avoid throwing the NPE when downgrading the request.

@@ -371,8 +371,7 @@ private void doSend(ClientRequest clientRequest, boolean isInternalRequest, long
} catch (UnsupportedVersionException e) {
// If the version is not supported, skip sending the request over the wire.
// Instead, simply add it to the local queue of aborted requests.
log.debug("Version mismatch when attempting to send {} to {}",
clientRequest.toString(), clientRequest.destination(), e);
log.debug("Version mismatch when attempting to send {} to {}", builder, clientRequest.destination(), e);

Choose a reason for hiding this comment

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

One thing from the ClientRequest that we don't get from the builder is the correlationId. This is occasionally useful when debugging. If you think it's useful, we might consider adding it to the log lines in doSend as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hehe, I was debating that. Since other places didn't seem to be doing it, I did not do it here either. I pushed additional commits attempting to do this and improve how we output node information. Please take a look.

@ijuma ijuma force-pushed the kafka-5506-offset-fetch-request-to-string-npe branch from 47bdaf8 to 1e353cb Compare June 23, 2017 18:38
Copy link

@hachikuji hachikuji left a comment

Choose a reason for hiding this comment

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

LGTM. I love to see logging improvements.

@asfgit
Copy link

asfgit commented Jun 23, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/5675/
Test PASSed (JDK 7 and Scala 2.11).

@asfgit
Copy link

asfgit commented Jun 23, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/5661/
Test PASSed (JDK 8 and Scala 2.12).

asfgit pushed a commit that referenced this pull request Jun 24, 2017
…ements

NetworkClient's logging improvements:
- Include correlation id in a number of log statements
- Avoid eager toString call in parameter passed to log.debug
- Use node.toString instead of passing a subset of fields to the
logger
- Use requestBuilder instead of clientRequest in one of the log
statements

Author: Ismael Juma <ismael@juma.me.uk>

Reviewers: Damian Guy <damian.guy@gmail.com>, Jason Gustafson <jason@confluent.io>

Closes #3420 from ijuma/kafka-5506-offset-fetch-request-to-string-npe

(cherry picked from commit a5c47db)
Signed-off-by: Ismael Juma <ismael@juma.me.uk>
@asfgit asfgit closed this in a5c47db Jun 24, 2017
@asfgit
Copy link

asfgit commented Jun 24, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/5683/
Test PASSed (JDK 7 and Scala 2.11).

@asfgit
Copy link

asfgit commented Jun 24, 2017

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/5669/
Test PASSed (JDK 8 and Scala 2.12).

@ijuma ijuma deleted the kafka-5506-offset-fetch-request-to-string-npe branch September 5, 2017 08:40
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