Thanks, Chris and Jeremy.
I've fixed the errors that Chris mentioned. I agree with Jeremy that this
KIP is limited to the framework dealing with these contexts as part of its
logging mechanism, and they're not really for connectors to use. Connector
implementations that don't have additional threa
Chris is correct the examples are mixed but it's pretty easy to
follow. From what I have gathered it looks like manipulation of the
context would be handled by the framework and not necessarily for the
connector developer. I'm not sure what benefit a connector developer
would have to manipulate the
Thanks, Konstantine. I'm not sure it's within the scope of this PR to
address the `worker.id` MDC parameter, especially because the behavior is
not yet well defined as to what happens when the `client.id` is set to a
non-unique value. I guess I'd prefer to limit the scope to just the
additional con
Thanks for the quick updates on the KIP Randall!
3. Indeed. I thought I remembered some ambiguity in the numbering of tasks,
but looking closer I think we are fine, especially now that you mention
explicitly 0-based indexing for task ids.
4. Fine with the example as is.
5. Sounds good.
6. "client.
Hi Randall,
Thanks for the KIP. Debugging Connect workers definitely becomes harder as
the number of connectors and tasks increases, and your proposal would
simplify the process of sifting through logs and finding relevant
information faster and more accurately.
I have a couple small comments:
F
Thanks for the review and feedback, Konstantine.
1. Great suggestion. I've updated the KIP to hopefully make it more clear
that the uncommented line is unchanged from the existing Log4J
configuration file.
2. Regarding including a `-` before the task number is acceptable if it
makes it easier to,
Thanks for the KIP Randall.
It might not be obvious right away, but this is a great improvement when
running Connect with multiple connectors or when debugging Connect, for
instance in integration tests or system tests. KIP looks good to me
overall, I have just a few comments below:
1. In the sni
I've been working on https://github.com/apache/kafka/pull/5743 for a while,
but there were a number of comment, suggestions, and mild concerns on the
PR. One of those comments was that maybe changing the Connect log content
in this way probably warrants a KIP. So here it is:
https://cwiki.apache.o
