You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why we don't expose partition directly is because we want to make Decaton agnostic to Kafka as much as possible (yeah, I know already there are some places where Kafka-specific thing is exposed though...).
To report per-partition error count even on deferredCompletion is an option though, the problem is how Decaton can know deferred-completion is "failed".
Given these, we are still not sure what's the best way to address the problem.
By the way let me ask if accessing through MDC causes another (e.g. performance) issue, not only the inconvenience.
There are cases where I need to reference the topic partition for metrics purposes.
While it's possible to force a reference through the MDC injected by LoggingContext, I would prefer a more direct method.
decaton/processor/src/main/java/com/linecorp/decaton/processor/LoggingContext.java
Line 52 in e0f6dc9
Even just adding getters to the various fields of LoggingContext would be helpful, but it might deviate from the original purpose of LoggingContext.
To elaborate on the use case, when using deferCompletion, the
decaton.tasks.error
metrics cannot be used, so I want to record the metrics myself. In this case, I need to reference the partition topic.https://github.com/line/decaton/blob/master/docs/monitoring.adoc#:~:text=in%20a%20topic.-,decaton.tasks.error,-The%20number%20of
(In other words, if
decaton.tasks.error
could be recorded even when using deferCompletion, that would be fine as well.)The text was updated successfully, but these errors were encountered: