Mailing-List: contact kafka-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: kafka-dev@incubator.apache.org
Date: Mon, 3 Sep 2012 05:01:07 +1100 (NCT)
From: "Prashanth Menon (JIRA)" <jira@apache.org>
To: kafka-dev@incubator.apache.org
Message-ID: <1756854589.28853.1346608867933.JavaMail.jiratomcat@arcas>
In-Reply-To: <107606995.59139.1340754104378.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Updated] (KAFKA-376) expose different data to fetch
 requests from the follower replicas and consumer clients
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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-v5.patch

Thanks for taking a look, Jun.  I've attached a new patch that ddresses the following items:
- readMessageSet now returns Either[Short, (MessageSet, Long)] where, on success, we return both the messages and the highwatermark of the leader.
- availableFetchBytes now logs info when it gets an UnknownTopicOrPartitionException exception, and logs an error for any other exceptions.

I tried to fiddle with EasyMock to get around the optional argument issue, but had no luck with it.  Seems like Mockito get's around it by mocking out all possible invocations permuting the parameters which is a little nasty.

Let me know what you think.
                
> 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, KAFKA-376-v3.patch, KAFKA-376-v4.patch, KAFKA-376-v5.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
For more information on JIRA, see: http://www.atlassian.com/software/jira