Anindya, On Wed, 15 Jan 2020 at 16:49, Anindya Haldar <anindya.hal...@oracle.com> wrote:
> In our case, the minimum in-sync replicas is set to 2. > > Given that, what will be expected behavior for the scenario I outlined? > This means you will get confirmation when 2 of them have acknowledged. so you will always have 2 in-sync. Perhaps drilling each detail and having a long thread, you could explain what is it you are trying to investigate/identify? We will be happy to help. Regards, > Sincerely, > Anindya Haldar > Oracle Responsys > > > > On Jan 15, 2020, at 6:38 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > > To all the in-sync replicas. You can set the minimum number of in-sync > > replicas via the min.insync.replicas topic/broker config. > > > > Ismael > > > > On Tue, Jan 14, 2020 at 11:11 AM Anindya Haldar < > anindya.hal...@oracle.com> > > wrote: > > > >> I have a question related to the semantics of a producer send and the > get > >> calls on the future returned by the send call. > >> > >> - It is a Java application, using the Kafka Java client library > >> - The application is set up to use 3 replicas and using acks=all for the > >> producer > >> - the application is using a non-zero value for linger.ms and > batch.size > >> parameters > >> - The application is using a single non-transactional Kafka producer > >> instance, shared across a number of threads > >> > >> With that, > >> > >> - Any application thread makes a send() call on the producer. > >> - Then the same thread calls get() on the future returned by the last > >> send() call > >> - The get() call on the future returns after it gets the acknowledgement > >> from the system for the message send > >> > >> At this point, is it guaranteed that the message has actually been > written > >> (but may not be committed by calling fsync) to ALL of the replicas’ > >> filesystems? > >> > >> Sincerely, > >> Anindya Haldar > >> Oracle Responsys > >> > >> > >
