> 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
> 
>

Reply via email to