Fix KafkaAppender reporting error after successful retry#4125
Open
SebTardif wants to merge 2 commits into
Open
Fix KafkaAppender reporting error after successful retry#4125SebTardif wants to merge 2 commits into
SebTardif wants to merge 2 commits into
Conversation
When retryCount is configured and the initial tryAppend() fails, the retry loop uses break to exit on success. However, break only exits the while loop and execution always reaches the error() call afterward. This causes spurious error notifications for transient Kafka failures that were successfully recovered by a retry. Replace break with return so that a successful retry exits append() without reporting an error. Retry exceptions are now logged at DEBUG level for diagnostics instead of being silently discarded. Also remove dead code in Builder.getRetryCount() where Integer.valueOf(int) was wrapped in a NumberFormatException catch that can never fire. The bug was introduced in apache#315. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
Contributor
ramanathan1504
left a comment
There was a problem hiding this comment.
LGTM overall — great fix for the break/return retry behavior, and thanks for adding DEBUG logging plus cleaning up getRetryCount().
One small suggestion commented to keep the diff minimal: retain the existing while loop shape and just apply the early return + DEBUG logging inside it.
| int currentRetryAttempt = 0; | ||
| while (currentRetryAttempt < this.retryCount) { | ||
| currentRetryAttempt++; | ||
| if (this.retryCount != null && this.retryCount > 0) { |
Contributor
There was a problem hiding this comment.
if (this.retryCount != null) {
int currentRetryAttempt = 0;
while (currentRetryAttempt < this.retryCount) {
currentRetryAttempt++;
try {
tryAppend(event);
return; // Fix: Exit early on success
} catch (final Exception retryException) {
LOGGER.debug(
"Unable to write to Kafka in appender [{}], retry attempt [{}/{}].",
getName(),
currentRetryAttempt,
this.retryCount,
retryException);
}
}
}
This still applies all three of your excellent fixes (early return, no swallowed exceptions, and preserving the stack trace in debug mode) but modifies fewer lines of code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix KafkaAppender retry logic that always reports an error to the error handler even when a retry succeeds.
When
retryCountis configured and the initialtryAppend()fails, the retry loop usesbreakto exit on success. However,breakonly exits thewhileloop; execution always reaches theerror()call afterward. This causes spurious error notifications for transient Kafka failures that were successfully recovered by a retry.This change replaces
breakwithreturnso that a successful retry exitsappend()without reporting an error. Retry exceptions are now logged at DEBUG level for diagnostics instead of being silently discarded.Also removes dead code in
Builder.getRetryCount()whereInteger.valueOf(int)was wrapped in aNumberFormatExceptioncatch that can never fire.The bug was introduced in #315.
Checklist
2.xbranch if you are targeting Log4j 2; usemainotherwise./mvnw verifysucceeds (the build instructions)