log truncation did not happen on old leader?

Hi there! We are running kafka 0.11.0 with 0.10.0 message format configured for a topic The topic has 1 partition + 3 replicas, unclean.leader.election.enable is set to false. We have reasons to believe that an old partition leader did not truncate its dirty log tail before syncing with new

Re: 0.8.x consumer group protocol

many unofficial clients that have implemented group > management for 0.8 (unless they are just wrapping the official library > running on the jvm). > > -Dana > On May 4, 2016 02:52, "Zaiming Shi" <zmst...@gmail.com> wrote: > > Hi there! > > I'm investigating

0.8.x consumer group protocol

Hi there! I'm investigating what it means to implement consumer group protocol for 0.8. However all the documents I can find on line is for 0.9 e.g. https://cwiki.apache.org/confluence/display/KAFKA/Kafka+0.9+Consumer+Rewrite+Design Also, in kafka code base, JOIN_GROUP_REQUEST_V0 schema in 0.8

Re: consumer group, why commit requests are not considered as effective heartbeats?

we can see what others think. Out of curiosity, is this a > significant problem for the Erlang client you're writing? > > -Jason > > On Fri, Mar 25, 2016 at 1:38 PM, Zaiming Shi <zmst...@gmail.com> wrote: > > > Hi Jason > > > > If I understand correctly, when coordinato

Re: consumer group, why commit requests are not considered as effective heartbeats?

ge. Can you post some logs from the consumer around the time that the > unexpected rebalance occurred? > > -Jason > > On Fri, Mar 25, 2016 at 12:09 AM, Zaiming Shi <zmst...@gmail.com> wrote: > > > Hi Jason > > > > thanks for the reply! > > > >

Re: consumer group, why commit requests are not considered as effective heartbeats?

-Jason > > > > On Wed, Mar 23, 2016 at 10:03 AM, Zaiming Shi <zmst...@gmail.com > <javascript:;>> wrote: > > > Hi there! > > > > We have noticed that when committing requests are sent intensively, we > > receive IllegalGenerationId.

consumer group, why commit requests are not considered as effective heartbeats?

Hi there! We have noticed that when committing requests are sent intensively, we receive IllegalGenerationId. Here is the settings we had problem with: session-timeout: 30 sec, heartbeat-rate: 3 sec. Problem resolved by increasing the session timeout to 180 sec. So I suppose, due to whatever

kafka protocol BNF file ?

Hi there! Any one know if there is an official bnf grammar file for download ? --- so that I don't have to do copy-pastes from the wiki page Regards -Zaiming

Re: querying messages based on timestamps

Hi Jiangjie ! Does the word 'Currently' imply any plan in introducing timestamp in log entries? Regards /Zaiming On Jun 30, 2015 11:08 PM, Jiangjie Qin j...@linkedin.com.invalid wrote: Currently Kafka only have a very coarse solution to find offset by time, which is based on the segment last

Re: unclean leader election enable default value bug?

at 1:54 PM, Zaiming Shi zmst...@gmail.com wrote: Hi Again! Unlike min.insync.replicas, unclean.leader.election.enable isn't set to false even if it's given 'false' in create topic command. here is the command used to create the topic: $./kafka-topics.sh --create --topic bbb --zookeeper

Re: unclean leader election enable default value bug?

- 60480, segment.jitter.ms - 0}. (kafka.log.LogManager) Is this a known issue? is there a workaround ? or have I missed anything ? On Thu, Jun 18, 2015 at 12:51 PM, Zaiming Shi zmst...@gmail.com wrote: Kafka 0.8.2.1 I have `unclean.leader.election.enable=false` in server.properties I can see

unclean leader election enable default value bug?

Kafka 0.8.2.1 I have `unclean.leader.election.enable=false` in server.properties I can see this log in server.log: [2015-06-18 09:57:18,961] INFO Property unclean.leader.election.enable is overridden to false (kafka.utils.VerifiableProperties) Yet the topic was created with