[
https://issues.apache.org/jira/browse/KAFKA-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295113#comment-15295113
]
Otis Gospodnetic commented on KAFKA-3632:
-----------------------------------------
Wow, could this be a fix for the problem described in this thread:
http://search-hadoop.com/m/uyzND1vNarT5XZpK&subj=Re+Consumer+lag+lies+orphaned+offsets
?
And could this be a related, or even a fix for KAFKA-2530?
> ConsumerLag metrics persist after partition migration
> -----------------------------------------------------
>
> Key: KAFKA-3632
> URL: https://issues.apache.org/jira/browse/KAFKA-3632
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.8.2.2, 0.9.0.1
> Environment: JDK 1.8, Linux
> Reporter: Brian Lueck
> Assignee: Jason Gustafson
> Priority: Minor
> Fix For: 0.10.0.0
>
>
> When a partition is migrated away from a broker, the ConsumerLag metric for
> the topic/partition gets 'stuck' at the current value. The only way to remove
> the metric is to restart the broker.
> This appears to be because in AbstractFetcherThread.scala there is no way of
> removing a metric. See...
> {code}
> class FetcherLagStats(metricId: ClientIdAndBroker) {
> private val valueFactory = (k: ClientIdTopicPartition) => new
> FetcherLagMetrics(k)
> val stats = new Pool[ClientIdTopicPartition,
> FetcherLagMetrics](Some(valueFactory))
> def getFetcherLagStats(topic: String, partitionId: Int): FetcherLagMetrics =
> {
> stats.getAndMaybePut(new ClientIdTopicPartition(metricId.clientId, topic,
> partitionId))
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
