Need Swift revert - for Kafka solution

Hi Apache Kafka Team, This to inform, one of our customer seeking open source solution on distributed streaming platform & tolerant storage. Thought your solutions suits well. Request you to call/revert back on priority as timeline for immediate closure. If am not accessible, plz contact our

Is Zombie instance problem consumer related ?

Kafka documentation states: Finally, in distributed environments, applications will crash or—worse!—temporarily lose connectivity to the rest of the system. Typically, new instances are automatically started to replace the ones which were

Re: Partitioning issue when a broker is going down

If your producer is set to use acks=all, then it won’t be able to produce to the topic topic partitions that had replicas on the missing broker until the replacement broker has finished catching up to be included in the ISR. What method are you using that reports on the number of topic

Partitioning issue when a broker is going down

Hi, Kafka cluster with 3 brokers, version 1.0.1. Topic with 15 partitions, replication factor 2. All replicas in sync. Bringing down one of the brokers (ungracefully), then adding a broker in version 1.0.1 During this process, are we expected either of the following to happen: 1. Some of

Re: Partitioning issue when a broker is going down

> On May 17, 2020, at 11:45 AM, Victoria Zuberman > wrote: > >  Regards acks=all: > - > Interesting point. Will check acks and min.insync.replicas values. > If I understand the root cause that you are suggesting correctly, given my > RF=2 and 3 brokers in cluster: >

Re: Partitioning issue when a broker is going down

Regards acks=all: - Interesting point. Will check acks and min.insync.replicas values. If I understand the root cause that you are suggesting correctly, given my RF=2 and 3 brokers in cluster: min.insync.replicas > 1 and acks=all, removing one broker ---> partition

Question on Kafka Connect

I'm looking at deploying Kafka Connect for a simple export cluster. I'm trying to understand how the connectors are loaded. Are the connectors getting deployed through a process "fork" and they are monitored via the Kafka Connect workers. Or is the connector just instantiated inside a Kafka worker

Re: Is Zombie instance problem consumer related ?

That is correct, but you don't need to worry about it. Kafka Streams takes care of this problem for you. -Matthias On 5/17/20 5:55 AM, Raffaele Esposito wrote: > Kafka documentation > states: > > Finally, in distributed environments,

Re: data structures used by GlobalKTable, KTable

Your request is out-of-scope for the KIP. Sorry. Kafka Streams ships with an in-memory LRU-store though -- however, this store would never go back to the topic. It just caches bases on LRU and if data is evicted it's gone. Going back to the topic would not be feasible anyway, because there is no

Re: Partitioning issue when a broker is going down

Regards number of partitions: Still don't understand it fully. I revisited Java default partitioner. I see that there available partitions are used only when key is not provided (virtually when it is round-robin). When key is provided, it uses number of partitions (regardless of availability).