Thanks for the quick response, Tom, and thanks again for tweaking the
wording on KIP-676. We can absolutely revisit this in the future if it
becomes more of an issue.
If anyone else disagrees, please say so.
Best regards,
Randall
On Mon, Jan 25, 2021 at 9:19 AM Tom Bentley wrote:
> Hi
Hi Randall,
I agree that Kafka Connect's API is more usable given that the user of it
knows the semantics (and KIP-495 is clear on that point). So perhaps this
inconsistency isn't enough of a problem that it's worth fixing, at least
not at the moment.
Kind regards,
Tom
On Fri, Jan 22, 2021 at
Thanks for updating the wording in KIP-676.
I guess the best path forward depends on what we think needs to change. If
we think KIP-676 and the changes already made in AK 2.8 are not quite
right, then maybe we should address this either by fixing the changes (and
maybe updating KIP-676 as needed)
Hi Randall,
Thanks for pointing this out. You're quite right about the behaviour of the
LoggingResource, and I've updated the KIP with your suggested wording.
However, looking at it has made me realise that while KIP-676 means the
logger levels are now hierarchical there's still an inconsistency
Tom, et al.,
I'm really late to the party and mistakenly thought the scope of this KIP
included only the broker. But I now see in the KIP-676 [1] text the
following claim:
Kafka exposes a number of APIs for describing and changing logger levels:
>
> * The Kafka broker exposes the DescribeConfigs
Hi Tom,
I also agree that the current behavior is clearly wrong and I think it was
mistakenly omitted in the KIP-412 discussion process. The current
implementation does not reflect log4j's logger hierarchy.
Regards,
Dongjin
On Thu, Oct 8, 2020 at 1:27 AM John Roesler wrote:
> Ah, thanks Tom,
Ah, thanks Tom,
My only concern was that we might silently start logging a
lot more or less after the upgrade, but if the logging
behavior won't change at all, then the concern is moot.
Since the KIP is only to make the APIs return an accurrate
representation of the actual log level, I have no
Hi John,
You're right, but note that this affects the level the broker/connect
worker was _reporting_ for that logger, not the level at which the logger
was actually logging, which would be TRACE both before and after upgrading.
I've added more of an explanation to the KIP, since it wasn't very
Thanks for this KIP Tom,
Just to clarify the impact: In your KIP you described a
situation in which the root logger is configured at INFO, an
"kafka.foo" is configured at TRACE, and then "kafka.foo.bar"
is resolved to INFO.
Assuming this goes into 3.0, would it be the case that if I
had the
Hi all,
I would like to start discussion on a small KIP which seeks to rectify an
inconsistency between how Kafka reports logger levels and how logger
configuration is inherited hierarchically in log4j.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-676%3A+Respect+logging+hierarchy
10 matches
Mail list logo
