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

DeadLetterPublishingRecoverer should respect onlyLogRecordMatadata listener property #2268

Closed
kdowbecki opened this issue May 11, 2022 · 7 comments
Assignees
Milestone

Comments

@kdowbecki
Copy link
Contributor

kdowbecki commented May 11, 2022

Expected Behavior

Currently the org.springframework.kafka.listener.KafkaMessageListenerContainer class has onlyLogRecordMatadata property that governs how ConsumerRecord is logged on processing failure. Same onlyLogRecordMatadata property should be respected by the org.springframework.kafka.listener.DeadLetterPublishingRecoverer class for ProducerRecord.

Current Behavior

DeadLetterPublishingRecoverer currently logs the whole ProducerRecord when publication fails with no option to switch to just the metadata.

Context

We already have set onlyLogRecordMatadata = true because we don't want the message payload to appear in the logs when something fails. Since DeadLetterPublishingRecoverer copies the payload from the failed message into a ProducerRecord we still see the original message payload in the logs when publication fails.

@garyrussell
Copy link
Contributor

garyrussell commented May 11, 2022

Which version are you using? And which log message specifically?

It looks like all logs in 2.8.x properly log the record; in 2.7.x, I see one debug and 2 exceptions that log the producer record.

@garyrussell
Copy link
Contributor

That flag only controls logging of the consumer record.

The DLPR does log the producer record; in 2.8 we added a new feature to format the logs for producer record.

/**
* Set a formatter for logging {@link ProducerRecord}s.
* @param formatter a function to format the record as a String
* @since 2.7.12
*/
public static void setProducerRecordFormatter(Function<ProducerRecord<?, ?>, String> formatter) {
Assert.notNull(formatter, "'formatter' cannot be null");
prFormatter = formatter;
}

The default formatter logs the full record.

@garyrussell garyrussell modified the milestone: 2.7.14 May 11, 2022
@garyrussell
Copy link
Contributor

Although it was back-ported to 2.7.x, the DLPR doesn't use it.

@kdowbecki
Copy link
Contributor Author

kdowbecki commented May 11, 2022

Good point @garyrussell. I'm on 2.7.12. I don't see DeadLetterPublishingRecoverer using KafkaUtils formatting in these lines:

this.logger.error(ex, () -> "Dead-letter publication failed for: " + outRecord);

throw new KafkaException("Publication failed for: " + outRecord, e);

@kdowbecki
Copy link
Contributor Author

It might be useful if failIfSendResultIsError field and verifySendResult method are changed from private to protected just like publish method is already protected. That way when when someone wants to override publish they can still reuse failIfSendResultIsError + verifySendResult functionality.

@garyrussell
Copy link
Contributor

Yes, I will do some polishing around that at the same time; we don't allow protected fields (except loggers), but I can add a getter for it.

garyrussell added a commit to garyrussell/spring-kafka that referenced this issue May 11, 2022
Resolves spring-projects#2268

2.7.x Only

The DLPR was incorrectly logging the full `ProducerRecord`; later versions
log the original `ConsumerRecord` using `KafkaUtils.format()`.
Backport the logging changes, but use a `ThreadLocal` for the input record
to avoid API changes in a patch release.
artembilan pushed a commit that referenced this issue May 11, 2022
Resolves #2268

2.7.x Only

The DLPR was incorrectly logging the full `ProducerRecord`; later versions
log the original `ConsumerRecord` using `KafkaUtils.format()`.
Backport the logging changes, but use a `ThreadLocal` for the input record
to avoid API changes in a patch release.
@garyrussell
Copy link
Contributor

Closed by 56b7756

(Not sure why this didn't auto-close).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants