Kafka

Hi, I am encountering an issue with how timestamp headers are serialized in Kafka Connect and would appreciate clarification on whether this is the intended behavior or a bug. Problem: Incorrect Serialization of Midnight UTC Timestamps When using connectors that produce timestamp headers (e.g., the MongoDB source connector), timestamps that fall exactly at midnight UTC are being serialized incorrectly, losing their time component. Timestamps at any other time of day are serialized correctly. Example: - Input Timestamp: 2025-01-01T00:00:00.000Z (midnight UTC) - Expected Serialized Value: "2025-01-01T00:00:00.000Z" - Actual Serialized Value: "2025-01-01" (time component lost) Analysis I traced this to the org.apache.kafka.connect.data.Values.dateFormatFor() < https://github.com/apache/kafka/blob/0e1c6fb6bb503aeda27ce1d73cd827b7a227d769/connect/api/src/main/java/org/apache/kafka/connect/data/Values.java#L769-L777 > which determines the format...

Cf https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy ? In general, we maintain 3 versions, so with AK 4.2 release, 3.9.x would actually hit EOL. Given that 4.0 is a major change with ZK removal in favor of KRaft, it will most likely be maintained a little longer though. We are currently discussing a 3.9.2 bug-fix release. But it will depend on overall community demand, if their will be a 3.9.3 bug-fix release or not. In general, I would not expect 3.9.x to be maintained too much longer, and migrating off ZK, and to upgrade to 4.x is highly recommended. -Matthias On 11/24/25 9:15 PM, Ranjan, Ravi via users wrote: > Hi > > Trying to gauge the eol for Kafka 3.9.1. I could figure out dates for Kafka 3.9 https://endoflife.date/apache-kafka but not for 3.9.1 Please help. > > > Regards > > Ravi Ranjan > > Senior Manager, Blue Plant Systems Design Archi...

Hi kafka team, Can someone confirm if this KIP is resolved yet - https://issues.apache.org/jira/browse/KAFKA-15513 ? Or timeline for the same? I could get it to work for sasl_ssl/scram-sha in broker-broker and broker-client communication. But this still fails for controller-controller and broker-controller communication. -- Regards, Chitrangna

Hi Trying to gauge the eol for Kafka 3.9.1. I could figure out dates for Kafka 3.9 https://endoflife.date/apache-kafka but not for 3.9.1 Please help. Regards Ravi Ranjan Senior Manager, Blue Plant Systems Design Architecture | Ciena Gurgaon, Haryana

Hi Kafka Team, Currently, I am exploring Kafka's capabilities to store data (acting as a Data Lake) and forward data (acting as a Data Pipeline) for specific logs to multiple analytics solutions. I have reviewed many documents online, but I need some clarification from you. I would like to confirm whether Kafka can meet the following requirements: 1. *Local Data Lake*: The data lake must be hosted locally to ensure high availability. 2. *Data Filtering*: We need the ability to filter logs and forward only selected logs to specific destinations. 3. *Multi-Destination Log Forwarding*: The data pipelines should support forwarding logs to multiple destinations. Could you please advise whether Kafka supports these capabilities? Any relevant documentation or guidance would also be greatly appreciated. Thank you for your assistance, and I look forward to your response Regards, Thanawat

Hi Kafka Team, Currently, I am exploring Kafka's capabilities to store data (acting as a Data Lake) and forward data (acting as a Data Pipeline) for specific logs to multiple analytics solutions. I have reviewed many documents online, but I need some clarification from you. I would like to confirm whether Kafka can meet the following requirements: 1. *Local Data Lake*: The data lake must be hosted locally to ensure high availability. 2. *Data Filtering*: We need the ability to filter logs and forward only selected logs to specific destinations. 3. *Multi-Destination Log Forwarding*: The data pipelines should support forwarding logs to multiple destinations. Could you please advise whether Kafka supports these capabilities? Any relevant documentation or guidance would also be greatly appreciated. Thank you for your assistance, and I look forward to your response Regards, Thanawat

depends upon what are you running ! How many partitions and how much is the persec produce rate ! Abhit :wq On Thu, Nov 20, 2025 at 1:59 PM Esther Lim <esther.lim@nacosmarine.com.invalid> wrote: > Hi, > > > > May I know what is the system requirement for hosting Kafka on Windows 11? > Specifically the CPU, Memory and Disk space requirements. > > > > Best Regards, > > *Esther Lim* > Cyber Security (Operation Technology) Specialist > NACOS Marine > Mobile: +65 98318121 > esther.lim@nacosmarine.com > > > > > Nacos Marine Singapore Pte. Ltd. > 8 JURONG TOWN HALL ROAD #24-03/04, THE JTC SUMMIT SINGAPORE > , > Singapore > > > This email (including attachments) is confidential, may be legally > privileged and is meant solely for the use of the > intended addressee. If you have received this email by mistake, please > promptly notify the sender by telephone...

Hi,   May I know what is the system requirement for hosting Kafka on Windows 11? Specifically the CPU, Memory and Disk space requirements.   Best Regards,   Esther Lim Cyber Security (Operation Technology) Specialist NACOS Marine Mobile: +65 98318121 esther.lim@nacosmarine.com   Nacos Marine Singapore Pte. Ltd. 8 JURONG TOWN HALL ROAD #24-03/04, THE JTC SUMMIT SINGAPORE  , Singapore This email (including attachments) is confidential, may be legally privileged and is meant solely for the use of the intended addressee. If you have received this email by mistake, please promptly notify the sender by telephone or  return email and destroy all copies of this email. Please note that reading, disclosing, or any other kind of processing of this email by anyone else but the intended addressee is strictly prohibited and may also be unlawful. Receipt by anyone other than the intend...

Hi - I would check that you sufficient consumers per group and partitions to start with - slow consumers can impact latency - Little's Law can help you understand/tune the number of consumers/partitions as Concurrency = TP x RT; as RT (consumer latency increases) you need more concurrency (consumers/partitions) to achieve a target throughput (TP). And more partitions may need more cluster resources. If order doesn't matter so much you could even try out the new Kafka share groups! (Queues for Kafka) - as you can have more consumers than partitions, and less batching (potentially even a batch size of 1), Regards, Paul From: Jose Manuel Monroy < jose.monroy@evokeplc.com > Date: Monday, 17 November 2025 at 8:50 pm To: Users < users@kafka.apache.org > Cc: Cezary Gajdzinski < Cezary.Gajdzinski@evokeplc.com >, Slawomir Kmiecik < slawomir.kmiecik@grandparade.co.uk >, Wojciech Frycz < Wojciech.Frycz@grandparade.co.uk > Subject: Kafka producer and ...

Hi, I'm seeing a puzzling behavior with Flink's Kafka Sink and I'd like to understand if this is expected Kafka client behavior. Setup * Kafka cluster with 3 brokers * I provide 2 broker IPs of the same Kafka cluster in bootstrap.servers, for example: * bootstrap.servers= 10.1.1.10:9092 , 10.1.1.11:9092 * Flink Kafka Sink parallelism = 2 * Both Flink subtasks run in the same Kubernetes cluster (same TaskManager) Observed Behavior * Flink Sink Subtask #1 always connects to the first bootstrap IP (10.1.1.10). * Flink Sink Subtask #2 always connects to the second bootstrap IP (10.1.1.11). * This happens every time, consistently across job restarts. My expectation was that each KafkaProducer would try bootstrap servers in the order provided, i.e., try 10.1.1.10 → only fall back to 10.1.1.11 if the first one is unreachable. However, both brokers are healthy and reachable from my TaskManager pod, yet the second subtask ne...

Hi there, Since months ago, we noticed our Kafka producer is seeing from time to time request latency when trying to produce, and specific consumers (not sure if all of them since we have too many) seeing clearly fetch latency, which ending into Kafka lag, even sometimes producer and consumers are pretty aligned in latency peaks, and very often is clearly connected to high producing rate for certain topics at the same time, but even seeing when not so maybe something else happening. Historically (exactly from version 2.2.1) we have enabled idempotence following your official recommendation to not missing data or out of order, so could be root cause of bottleneck under pressure and explaining those latencies? If not, what else could explain such thing? Maybe topic throughput is going down for some reason? Do you have any recommendation what to verify? Thanks   Confidentiality notice : This email and its attachments are for the sole use of the inte...

I suppose a downtime of a cluster as a whole for a longer period (hours or even a day) is something you would usually never want to have, at least in most production clusters. Besides issues for consumers (and the scenario of potential loss of unconsumed messages you describe), this sounds like much trouble also for the producers which then of course also can't write any new data to the cluster during that downtime either. At least this would be for clusters / topics that are constantly being written to, which is a typical scenario for most kafka clusters. But still, to your point: I think setting the retention period larger (maybe even substantially larger) than any such maintenance windows you may want to anticipate for would be the most typical way to avoid such problems, if you can afford this in terms of available storage space. This of course also depends on the usual rate at which data is being written into the cluster. Or as alternative, you could also ...

Thanks for the response. You're right, a single broker downtime shouldn't impact consumer reads in a healthy replicated cluster. However, my concern is slightly different; I am referring to a scenario where the entire Kafka cluster is down (for example, due to a maintenance window or infrastructure issue) and is brought back up after the topic's retention period has already expired. In that case, since Kafka deletes segments purely based on timestamps, it might start deleting data immediately upon startup, even if the messages were never consumed. -----Original Message----- From: Artem Timchenko <artem.timchenko@bolt.eu.INVALID> Sent: 12 November 2025 19:13 To: users@kafka.apache.org Subject: Re: Query: Preventing Message Loss Due to Retention Expiry in Strimzi Kafka In production-grade clusters downtime of a single broker shouldn't prevent consumers from reading messages and catch up with the offset. What replication factor are you using? On ...

Hi Is there a good method to collect kafka metrics via command line instead of using grafana or console etc .. ? Thanks Rajesh [Out Of Office Alert – ] Rajesh G Naicken - Senior Software Engineer - Appliance Security and DR Architect Db2 Warehouse, IIAS, CP4DS & NPS IBM Data & AI www: www.ibm.com Email: rnaicken@in.ibm.com , Ph: +91 9177753780 "Do your best to make sure your actions affect others in a positive way" - Tri Hita Karana

In production-grade clusters downtime of a single broker shouldn't prevent consumers from reading messages and catch up with the offset. What replication factor are you using? On Wed, Nov 12, 2025 at 10:44 AM Prateek Kohli <prateek.kohli@ericsson.com.invalid> wrote: > Hi, > > I am looking for a reliable, production-safe strategy to avoid losing > unread messages when a Kafka broker remains down longer than the topic's > configured retention.ms . > > Since Kafka deletes segments purely based on timestamps, if a broker is > down for (for example) 24 hours and the topic's retention.ms is also 24 > hours, the broker may start deleting segments immediately on startup, even > if no consumers have read those messages yet. > > Is there a recommended way to prevent message loss in this scenario? > > I am running Kafka on Kubernetes using Strimzi, so all topic > configurations are managed through KafkaTopic CR...

Hi, I am looking for a reliable, production-safe strategy to avoid losing unread messages when a Kafka broker remains down longer than the topic's configured retention.ms . Since Kafka deletes segments purely based on timestamps, if a broker is down for (for example) 24 hours and the topic's retention.ms is also 24 hours, the broker may start deleting segments immediately on startup, even if no consumers have read those messages yet. Is there a recommended way to prevent message loss in this scenario? I am running Kafka on Kubernetes using Strimzi, so all topic configurations are managed through KafkaTopic CRDs and the Topic Operator. One solution could to be alter the topic's retention configuration. But for that to work I would need to ensure that its triggered before Kafka delete the log segments. So could something be done during startup? For example, with a 3-broker cluster, I could prevent the brokers from fully starting after the first pod comes up...

Hi, I am trying to fetch a consumer group description using kafka-python client. The returned describe response shows the state=Dead and doesnt list the committed offsets for the group.  I can see this group in the kafka-consumer-group CLI command and even the committed offsets.  What could be the reasons for getting a Dead state? Thanks,Chirag

To follow up further, it turns out I only *thought* I'd applied use.defaults.from (and source->target.use.defaults.from) - in the end neither were applied So it seems that setting config.properties.exclude and source->target.config.properties.exclude was the key fix on a fresh cluster replication. -- Disclaimer: This e-mail and any attachments may contain Confidential Information. If you are not the intended recipient, any disclosure, copying, distribution or use of any information contained herein is strictly prohibited. If you have received this transmission in error, please immediately notify the Security Officer, and destroy the original transmission and any attachments without reading or saving.

I think I was on the right lines here but I suspect the cycle detection in shouldReplicateTopic prevents source topics updating target topics with the same name - so once the topic configuration has been synced once, it will not be synced again. The combination of use.defaults.from = source and config.properties.exclude seems to have done the trick (in the end I set both use.defaults.from and source->target.use.defaults.from - I'm not sure whether that was necessary but also I didn't want to burn further hours on cluster rebuilds to work it out) and message.timestamp.difference.max.ms is now Long.MAX After a target cluster build the message replication appears to be proceeding without the timestamp validation rejections. -- Disclaimer: This e-mail and any attachments may contain Confidential Information. If you are not the intended recipient, any disclosure, copying, distribution or use of any information contained herein is strictly prohibited....

Using mirror maker 2 to replicate one cluster to another, we're getting a lot of message rejections due to timestamp out of range. [2025-11-12 00:58:46,727] ERROR [MirrorSourceConnector|task-0] WorkerSourceTask{id=MirrorSourceConnector-0} failed to send record to our.topic.name.goes.here: (org.apache.kafka.connect.runtime.AbstractWorkerSourceTask:419) org.apache.kafka.common.InvalidRecordException: Timestamp 1725218013643 of message with offset 7 is out of range. The timestamp should be within [1762822726723, 1762995526723] The range is one day plus or minus current time, which is a problem for a lot of our topics that might have 30 day retention, but also compacted topics which could have years old messages that need to be replicated. My analysis so far suggests that it is message.timestamp.difference.max.ms - even though this is a deprecated setting, we're using kafka 3.9 until our migration has completed, and that seems to be the setting that relates to...

In my production environment, I use [istio]( https://istio.io ), but istio enables TLS by default. so if based on [kafka docs]( https://kafka.apache.org/documentation/#maximizingefficiency ), sendfile is not used. So crazy. Is kafka still performing well? *It confuses me very much*

Hello everyone, today I know [Pulsar is a Top 10 Apache Software Foundation project]( https://pulsar.apache.org/ ). but where to find all Top 10 Apache Software Foundation projects in the official apache website. I can not find this information in the [Apache project lists]( https://projects.apache.org/projects.html )

Hi Kafka friends, We run a Kafka Streams app. Sometimes, multiple instances will run in parallel, with different application IDs - imagine "prod" vs "prod-next" vs "dev-experiment" We'd like to apply a metric tag to only the "prod" instance, so that when we build a Grafana dashboard, we can easily filter out experiments that are irrelevant to our monitoring. We'd like to avoid hard-coding the application id into the dashboard, since it can change from time to time and ultimately is free-form and provided by an operator. However, I cannot find a way to attach a custom tag to all Kafka metrics sent to the brokers. Is this possible? Thanks, Steven

+1 (non-binding). I used the staged binaries and run my own tests with it as well as the Strimzi system tests. All seems to work fine. Thanks for running the release. Jakub On Mon, Oct 27, 2025 at 4:35 PM Lianet M. < lianetmr@gmail.com > wrote: > Hello Kafka users, developers, and client-developers, > > This is the third candidate for the release of Apache Kafka 4.1.1. > > This is a bug-fix release, including several critical ones. All listed > in the release notes. > > Release notes for the 4.1.1 release: > https://dist.apache.org/repos/dist/dev/kafka/4.1.1-rc2/RELEASE_NOTES.html > > *** Please download, test, and vote by Friday, Oct 31th, 9:00 AM EDT > > Kafka's KEYS file containing PGP keys we use to sign the release: > https://kafka.apache.org/KEYS > > * Release artifacts to be voted upon (source and binary): > https://dist.apache.org/repos/dist/dev/kafka/4.1.1-rc2/ > > * Docker rel...