MINOR: Log4j Improvements on Fetcher#8629
Conversation
| RequestFuture<ClientResponse> future = client.send(fetchTarget, request); | ||
| // We add the node to the set of nodes with pending fetch requests before adding the | ||
| // listener because the future may have been fulfilled on another thread (e.g. during a | ||
| // listenerbecause the future may have been fulfilled on another thread (e.g. during a |
There was a problem hiding this comment.
I assume this was unintentional.
| List<ConsumerRecord<K, V>> partRecords = completedFetch.fetchRecords(maxRecords); | ||
|
|
||
| log.trace("Returning fetched records {} at offset {} for assigned partition {}", | ||
| partRecords, position, completedFetch.partition); |
There was a problem hiding this comment.
I feel logging all of the records even at TRACE level will be too much. For example, our system tests often have TRACE enabled. Huge single-line log messages are difficult to consume both visually and in systems like elastic.
There was a problem hiding this comment.
Makes sense, it is primarily for my local debugging of an integration test which only sends a couple records. I will only print the num.records instead.
|
@mjsax @hachikuji My previous investigation on this issue ended up in the broker-side |
* 'trunk' of github.com:apache/kafka: KAFKA-9290: Update IQ related JavaDocs (apache#8114) KAFKA-9928: Fix flaky GlobalKTableEOSIntegrationTest (apache#8600) KAFKA-6145: Set HighAvailabilityTaskAssignor as default in streams_upgrade_test.py (apache#8613) KAFKA-9667: Connect JSON serde strip trailing zeros (apache#8230) MINOR: Log4j Improvements on Fetcher (apache#8629)
Reviewers: Jason Gustafson <jason@confluent.io>
Committer Checklist (excluded from commit message)