line
Provide a method to reference the topic partition
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. https://github.com/line/decaton/blob/e0f6dc98814636bf71bb0689bb7874be40db7142/processor/src/main/java/com/linecorp/decaton/processor/LoggingContext.java#L52
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.)
Sorry for the delay of the reaction.
The motivation makes sense.
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.
Why we don't expose partition directly
I see. With the rise of many Kafka-compatible middleware solutions, it certainly makes sense to hide the implementation as much as possible.
By the way let me ask if accessing through MDC causes another (e.g. performance) issue, not only the inconvenience.
Since it's just reading from thread-local storage, there are no performance concerns.
For now, I'm satisfied with the feedback, so it's okay to close the issue.