KAFKA-20713: Lower level for client log on self-healing session not found#22617
KAFKA-20713: Lower level for client log on self-healing session not found#22617lianetm wants to merge 4 commits into
Conversation
| if (response.error() != Errors.NONE) { | ||
| log.info("Node {} was unable to process the fetch request with {}: {}.", | ||
| node, nextMetadata, response.error()); | ||
| if (response.error() == Errors.FETCH_SESSION_ID_NOT_FOUND) { |
There was a problem hiding this comment.
Do we also need to handle INVALID_FETCH_SESSION_EPOCH? I think that this in principle can happen when a network connection is lost and reconnected, and the recovery action is the same.
There was a problem hiding this comment.
updated.
The invalid epoch should not be as common I would imagine but still makes sense to log as in session not found as the handling and impact on the client is the same (none, self-healing). I imagine it's less common because the consumer sends a full fetch request upon errors, so would start a new session even if it carries an old epoch it seems (just sharing because I didn't know myself this on fetch, same approach in the consumer and heartbeats: full request upon errors with the GC). Btw, I ended up consolidating all other errors like the invalid epoch (all are top-level errors with that are handled the same: re-send full fetch with nextCloseExistingAttemptNew)
Lower to DEBUG and update message for the fetch session not found
(evicted) scenario. The previous INFO log reported this as an error, but
on the client side it is self-healing and not actionable.
Fetch sessions are managed on the broker, which already exposes the
visibility needed (metrics and logs) to detect this situation and
correct it (broker configs for fetch session cache)
Reviewers: Andrew Schofield aschofield@confluent.io