MINOR: Fixed way how logging methods are used for having a consistent one #3419
Conversation
|
Cc @dguy |
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
| @@ -72,7 +72,7 @@ public void makeReady(final Map<InternalTopicConfig, Integer> topics) { | |||
| streamsKafkaClient.createTopics(topicsToBeCreated, replicationFactor, windowChangeLogAdditionalRetention, metadata); | |||
| return; | |||
| } catch (StreamsException ex) { | |||
| log.warn("Could not create internal topics: " + ex.getMessage() + " Retry #" + i); | |||
| log.warn("Could not create internal topics. Retry #{} :", i, ex); | |||
There was a problem hiding this comment.
We don't really care about the stack trace here or below, just the message. We know the StreamsException is generated from this class and the message is enough to identify the problem. Further, these are done in a retry loop so can become quite verbose if failed multiple times
There was a problem hiding this comment.
@dguy just fixed even in the getNumPartitions method. thanks !
Fixed avoid the entire stack trace instead of the message only
ppatierno
force-pushed
the
streams-consistent-logging
branch
from
5a3d698
to
2ef61eb
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
Refer to this link for build results (access rights to CI server needed): |
In the stream library there are few cases where we don't leverage on logging methods features (i.e. using {} placeholder instead of string concatenation or passing the exception variable)