[ 
https://issues.apache.org/jira/browse/KAFKA-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prashanth Menon updated KAFKA-376:
----------------------------------

    Attachment: KAFKA-376-v2.patch

Hi all,

Find a second patch that addresses 20 and 21 (and some line spacing cleanup).  
It passes all the tests except for BackwardsCompatibilityTest; that test uses a 
pre-constructed log-data file that's loaded up when the Kafka server starts.  
The test then issues an offset request and pulls all the data back and expected 
100 messages total.  There are three issues here:

1) It looks like we need to handle the case where a topic/partition has a 
replication factor of one.  In such cases, updating the LEO of the log should 
also update the HW to the same value.  I took care of this in the patch, but 
I'd like some feedback on if it's the correct approach.
2) What should the server do on startup if it is a leader of a specific 
topic/partition and finds local data available for it.  Presumable, it should 
truncate it's log to the value in the checkpoint file, but it doesn't seem to 
be done now.  Is this thinking correct? 
3) KafkaApis should use the leader's HW to perform a bounds check when 
responding to an offset request.  It currently checks for leader presence, 
adding a check in should be relatively simple.  I can attach another patch with 
that (and any other issues that come up) mid-week.  
                
> expose different data to fetch requests from the follower replicas and 
> consumer clients
> ---------------------------------------------------------------------------------------
>
>                 Key: KAFKA-376
>                 URL: https://issues.apache.org/jira/browse/KAFKA-376
>             Project: Kafka
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 0.8
>            Reporter: Jun Rao
>            Assignee: Prashanth Menon
>              Labels: bugs
>         Attachments: KAFKA-376-DRAFT.patch, KAFKA-376-v1.patch, 
> KAFKA-376-v2.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Currently, the broker always uses highwatermark to calculate the available 
> bytes to a fetch request, no matter where the request is from. Instead, we 
> should use highwatermark for requests coming from real consumer clients and 
> use logendoffset for requests coming from follower replicas.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to