Kafka

Hi Alexander It's interesting and worth mulling it over. Would you mind opening a jira and KIP to propose this change? Best, Chia-Ping On 2026/08/18 08:34:09 Alexander Neubeck wrote: > Hi Kafka developers, > > KIP-32 describes LogAppendTime as monotonically increasing. However, the current implementation stamps records using the active leader’s local clock. > > After a leader election, the new leader’s clock may be behind the previous leader’s clock. In that case, newly appended records can receive a lower LogAppendTime than preceding records in the partition. > > A possible fix is for each partition leader to select: > > Plain text > > max(current broker time, previous LogAppendTime) > > > > The previous value can be recovered from the replicated log tail and maintained across follower appends, restart, truncation, and leader promotion. This guarantees nondecreasing timestamps without forcing a one-milli...

Hi, As per below mentioned ticket, CVE-2026-68497 fix will be included in kafka v4.4.0<https://issues.apache.org/jira/issues/?jql=project+%3D+KAFKA+AND+fixVersion+%3D+4.4.0> Is my understanding correct? Thanks Ashish Verma From: Gergely Harmadás <harmadasg@gmail.com> Sent: 31 August 2026 21:56 To: users@kafka.apache.org Cc: Ashish Verma V <ashish.v.verma@ericsson.com>; Vivek Agarwal B <vivek.b.agarwal@ericsson.com> Subject: Re: Kafka v4.3.0 Jackson related vulnerabilities Hello Luke and Vivek, I have gone ahead and created KAFKA-21004<https://issues.apache.org/jira/browse/KAFKA-21004> to track the CVE fix (also opened a PR) Regards, Gergely On Mon, 31 Aug 2026 at 11:10, Luke Chen <showuon@gmail.com<mailto:showuon@gmail.com>> wrote: Hi Vivek, Thanks for reporting this issue. Could you please open a JIRA <http://issues.apache.org/jira/browse/KAFKA> ticket for this issue? And if possible, welcome to create a...

Hello Luke and Vivek, I have gone ahead and created KAFKA-21004 <https://issues.apache.org/jira/browse/KAFKA-21004> to track the CVE fix (also opened a PR) Regards, Gergely On Mon, 31 Aug 2026 at 11:10, Luke Chen <showuon@gmail.com> wrote: > Hi Vivek, > > Thanks for reporting this issue. > Could you please open a JIRA > <http://issues.apache.org/jira/browse/KAFKA> ticket > for this issue? > And if possible, welcome to create a PR for it. > > From the current schedule, it should be included in v4.5.0. > > Thanks, > Luke > > On Mon, Aug 31, 2026 at 5:40 PM Vivek Agarwal B via users < > users@kafka.apache.org> wrote: > > > Hi, > > > > In our product, kafka v4.3.0 is used. Below Jackson related > vulnerability > > is reported on this kafka version - > > > > CVE-2026-68497 > > This vulnerability is fixed in jackson databind v2.21.6. I se...

Hi Vivek, Thanks for reporting this issue. Could you please open a JIRA <http://issues.apache.org/jira/browse/KAFKA> ticket for this issue? And if possible, welcome to create a PR for it. From the current schedule, it should be included in v4.5.0. Thanks, Luke On Mon, Aug 31, 2026 at 5:40 PM Vivek Agarwal B via users < users@kafka.apache.org> wrote: > Hi, > > In our product, kafka v4.3.0 is used. Below Jackson related vulnerability > is reported on this kafka version - > > CVE-2026-68497 > This vulnerability is fixed in jackson databind v2.21.6. I see upcoming > release kafka v4.4.0 bumped Jackson bind version to v2.21.5 > Please confirm which apache kafka upcoming versions will upgrade to > Jackson bind v2.21.6 > > Regards > Vivek > >

Hi, In our product, kafka v4.3.0 is used. Below Jackson related vulnerability is reported on this kafka version - CVE-2026-68497 This vulnerability is fixed in jackson databind v2.21.6. I see upcoming release kafka v4.4.0 bumped Jackson bind version to v2.21.5 Please confirm which apache kafka upcoming versions will upgrade to Jackson bind v2.21.6 Regards Vivek

Good Afternoon, Am looking to control log4j2 output produced by Kafka...but am having a little difficultly getting this to work as expected. During the kafka producer startup I've added this command: -Dlog4j2.configurationFile=/<whatever>/kafka/producers/log4j2.properties I've created a log4j2.properties file as follows: # Root Logger rootLogger=INFO, STDERR # Direct log messages to stderr appender.console.type = Console appender.console.name = STDERR appender.console.layout.type = PatternLayout appender.console.layout.pattern = [%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %C{1} - %msg%n Yet, when I look at STDERR am not seeing the desired messages. Do I need to configure slf4j instead or in conjunction? Anything I'm possibly doing wrong? Anyone with experience on customizing kafka message logging, will to chime in? Thank You, --Alex

Not sure if this is at all helpful, but we also experienced poor performance with Kafka Streams, and it took us quite a while to figure out all the tuning knobs, but we found that in our case we were experiencing extended RocksDB write stalls (overfilling memtables causing RocksDB to stall and eventually pause writes) which led to extended commit periods which led to large application latency gaps... I am not at all sure if you hit the same problem, but I would recommend enabling as many debug metrics as you can handle, turn on RocksDB stats logging, and in our case we ran a Claude Code instance with access to logs, dashboards, JFR dump (incl stack sampling) and it was actually quite good at identifying problematic configuration. You can't trust everything it says, but it can highlight things you didn't even consider... > On Aug 8, 2026, at 6:52 PM, Brebner, Paul via users <users@kafka.apache.org> wrote: > > Hi Tamar, > > Interesting problem...