[ https://issues.apache.org/jira/browse/KAFKA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823420#comment-15823420 ]
Ewen Cheslack-Postava commented on KAFKA-2500: ---------------------------------------------- [~hachikuji] [~rmetzger] [~willf] In light of https://cwiki.apache.org/confluence/display/KAFKA/KIP-92+-+Add+per+partition+lag+metrics+to+KafkaConsumer and the fact that metrics are exposed by the Consumer, should we consider just not implementing this? It looks like the same info (in a slightly different form) is now available via a different mechanism now. > Expose fetch response high watermark in ConsumerRecords > ------------------------------------------------------- > > Key: KAFKA-2500 > URL: https://issues.apache.org/jira/browse/KAFKA-2500 > Project: Kafka > Issue Type: Sub-task > Components: consumer > Affects Versions: 0.9.0.0 > Reporter: Will Funnell > Assignee: Jason Gustafson > Priority: Critical > Fix For: 0.10.2.0 > > > Originally created in the old consumer here: > https://issues.apache.org/jira/browse/KAFKA-1977 > The requirement is to create a snapshot from the Kafka topic but NOT do > continual reads after that point. For example you might be creating a backup > of the data to a file. > This ticket covers the addition of the functionality to the new consumer. > In order to achieve that, a recommended solution by Joel Koshy and Jay Kreps > was to expose the high watermark, as maxEndOffset, from the FetchResponse > object through to each MessageAndMetadata object in order to be aware when > the consumer has reached the end of each partition. > The submitted patch achieves this by adding the maxEndOffset to the > PartitionTopicInfo, which is updated when a new message arrives in the > ConsumerFetcherThread and then exposed in MessageAndMetadata. > See here for discussion: > http://search-hadoop.com/m/4TaT4TpJy71 -- This message was sent by Atlassian JIRA (v6.3.4#6332)