Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Kafka >> mail # dev >> Re: Review Request 15201: address previous review comments


+
Jun Rao 2013-11-11, 16:44
+
Neha Narkhede 2013-11-11, 19:06
+
Manoj Kunar 2013-11-11, 19:11
Copy link to this message
-
Re: Review Request 15201: address previous review comments


> On Nov. 5, 2013, 10:41 p.m., Guozhang Wang wrote:
> > core/src/main/scala/kafka/tools/ReplicaVerificationTool.scala, line 73
> > <https://reviews.apache.org/r/15201/diff/1/?file=377064#file377064line73>
> >
> >     We do not need () after withRequiredArg here.

done
> On Nov. 5, 2013, 10:41 p.m., Guozhang Wang wrote:
> > core/src/main/scala/kafka/tools/ReplicaVerificationTool.scala, line 115
> > <https://reviews.apache.org/r/15201/diff/1/?file=377064#file377064line115>
> >
> >     Ditto as above for these three.

done
> On Nov. 5, 2013, 10:41 p.m., Guozhang Wang wrote:
> > core/src/main/scala/kafka/tools/ReplicaVerificationTool.scala, line 120
> > <https://reviews.apache.org/r/15201/diff/1/?file=377064#file377064line120>
> >
> >     Why do we ask for all topics from brokers then filter them? Is this because the start-up brokers may not have metadata info for all the topics yet?

This is because the metadata api doesn't support get topics matching a regular expression.
> On Nov. 5, 2013, 10:41 p.m., Guozhang Wang wrote:
> > core/src/main/scala/kafka/tools/ReplicaVerificationTool.scala, line 274
> > <https://reviews.apache.org/r/15201/diff/1/?file=377064#file377064line274>
> >
> >     In think in this case the verification would stop and probably report the max lag for this topic-partition. This is also fine I think.

For an offset to move, all replicas must have received the message on that offset. Otherwise, the tool just keeps retrying.
> On Nov. 5, 2013, 10:41 p.m., Guozhang Wang wrote:
> > core/src/main/scala/kafka/tools/ReplicaVerificationTool.scala, line 361
> > <https://reviews.apache.org/r/15201/diff/1/?file=377064#file377064line361>
> >
> >     createNewVerificationBarrier here will set the count to 1, and then count it down to 0. So the next round the verification barrier count would be 1 and hence not holding other threads?

Not sure what your question is. Each fetch thread does the following in a loop:

1. fetch from the broker
2. wait for all threads to finish fetching
3. wait for verification to complete (only one threads does the verification)

The verification barrier is used so that all fetcher threads are in the right state in step 1.
- Jun
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15201/#review28162
-----------------------------------------------------------
On Nov. 11, 2013, 4:44 p.m., Jun Rao wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15201/
> -----------------------------------------------------------
>
> (Updated Nov. 11, 2013, 4:44 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1117
>     https://issues.apache.org/jira/browse/KAFKA-1117
>
>
> Repository: kafka
>
>
> Description
> -------
>
> kafka-1117; fix 2
>
>
> kafka-1117; fix 1
>
>
> kafka-1117
>
>
> Diffs
> -----
>
>   core/src/main/scala/kafka/tools/ReplicaVerificationTool.scala PRE-CREATION
>
> Diff: https://reviews.apache.org/r/15201/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Jun Rao
>
>
 
+
Jun Rao 2013-11-11, 16:56
+
Neha Narkhede 2013-11-11, 17:49