icas:
> 4,5,1,2,3 Isr: 3,4,2,5
> Topic: ${topic-name} Partition: 10 Leader: 5 Replicas:
> 5,2,3,4,1 Isr: 5,2,3,4
> Topic: ${topic-name} Partition: 11 Leader: 3 Replicas:
> 1,3,4,5,2 Isr: 5,2,3,4
> Topic: ${topic-name} Parti
367.4302
> Enterprise Architecture Team
> PDX-NHIN
>
>
> -Original Message-
> From: Shrikant Patel
> Sent: Wednesday, April 19, 2017 5:49 PM
> To: users@kafka.apache.org
> Subject: RE: [EXTERNAL] Re: Re: ZK and Kafka failover testing
>
> Thanks Jeff, Onur, Jun, Han
Patel
Sent: Wednesday, April 19, 2017 5:49 PM
To: users@kafka.apache.org
Subject: RE: [EXTERNAL] Re: Re: ZK and Kafka failover testing
Thanks Jeff, Onur, Jun, Hans. I am learning a lot from your response.
Just to summarize briefly my steps, 5 node Kafka and ZK cluster.
1. ZK cluster has all node
4,2,5,3
Thanks,
Shri
-Original Message-
From: Jeff Widman [mailto:j...@netskope.com]
Sent: Wednesday, April 19, 2017 4:11 PM
To: users@kafka.apache.org
Subject: [EXTERNAL] Re: Re: ZK and Kafka failover testing
* Notice: This email was received from an external source *
Oops, I l
t; > > ssl.truststore.type=JKS
>> > > max.in.flight.requests.per.connection=1
>> > > metadata.fetch.timeout.ms=6
>> > > reconnect.backoff.ms=1000
>> > > retry.backoff.ms=1000
>> > > max.request.size=1048576
>> > > li
es}
> > > value.deserializer= {appropriate value as per your case}
> > > group.id= {appropriate value as per your case}
> > > ssl.key.password= {appropriate value as per your case}
> > > ssl.keystore.location= {appropriate value as per your case}
> > > ssl.
tion= {appropriate value as per your case}
> > ssl.keystore.password= {appropriate value as per your case}
> > ssl.truststore.location= {appropriate value as per your case}
> > ssl.truststore.password= {appropriate value as per your case}
> > enable.auto.commit=false
> &
=false
> > security.protocol= SSL
> > ssl.enabled.protocols=TLSv1.2
> > ssl.keystore.type=JKS
> > ssl.protocol=TLSv1.2
> > ssl.truststore.type=JKS
> > client.id= {appropriate value as per your case, may help with
> debugging}
> > reconnect.backoff.ms=
JKS
> client.id= {appropriate value as per your case, may help with debugging}
> reconnect.backoff.ms=1000
> retry.backoff.ms=1000
>
> Thanks,
> Shri
>
> -Original Message-
> From: Hans Jespersen [mailto:h...@confluent.io]
> Sent: Tuesday, April 18,
]
Sent: Tuesday, April 18, 2017 7:57 PM
To: users@kafka.apache.org
Subject: [EXTERNAL] Re: ZK and Kafka failover testing
* Notice: This email was received from an external source *
When you publish, is acks=0,1 or all (-1)?
What is max.in.flight.requests.per.connection (default is 5)?
It
When you publish, is acks=0,1 or all (-1)?
What is max.in.flight.requests.per.connection (default is 5)?
It sounds to me like your publishers are using acks=0 and so they are not
actually succeeding in publishing (i.e. you are getting no acks) but they
will retry over and over and will have up to
Hi All,
I am seeing strange behavior between ZK and Kafka. We have 5 node in ZK and
Kafka cluster each. Kafka version - 2.11-0.10.1.1
The min.insync.replicas is 3, replication.factor is 5 for all topics,
unclean.leader.election.enable is false. We have 15 partitions for each topic.
The step we
12 matches
Mail list logo
