[
https://issues.apache.org/jira/browse/KAFKA-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14182670#comment-14182670
]
Vladimir Tretyakov commented on KAFKA-1481:
-------------------------------------------
Hi Jun, thx for your feedback again, attached new patch.
20.1 done.
20.2 "clientId" is "Taggable" here, it will convert to something like
"clientId=XXX" automatically
21 tags should be Map which iterators iterate in the same order elements were
inserted (final string must be stable): from LinkedHashMap docs "The iterator
and all traversal methods of this class visit elements in the order they were
inserted.". I am new in scala, if you know better candidate with predictable
iterators please let me know
22.1 done
22.2 clientId is not always just "clientId=XXX", look at:
{code}
class ConsumerFetcherThread(consumerFetcherThreadId: ConsumerFetcherThreadId,
val config: ConsumerConfig,
sourceBroker: Broker,
partitionMap: Map[TopicAndPartition,
PartitionTopicInfo],
val consumerFetcherManager: ConsumerFetcherManager)
extends AbstractFetcherThread(name = consumerFetcherThreadId,
clientId = new TaggableInfo(new
TaggableInfo("clientId" -> config.clientId), consumerFetcherThreadId),
sourceBroker = sourceBroker,
socketTimeout = config.socketTimeoutMs,
socketBufferSize =
config.socketReceiveBufferBytes,
fetchSize = config.fetchMessageMaxBytes,
fetcherBrokerId =
Request.OrdinaryConsumerId,
maxWait = config.fetchWaitMaxMs,
minBytes = config.fetchMinBytes,
isInterruptible = true) {
{code}
this "clientId = new TaggableInfo(new TaggableInfo("clientId" ->
config.clientId), consumerFetcherThreadId)" part was in code before my changes
(was manipulation with strings, not "Taggable" of course). Yeah, somewhere in
code we can use string instead of "Taggable", but maybe it is better to has
"Taggable" everywhere what is related to metrics. At least it was not easy to
me decide where I have to use "Taggable", but where I can leave string. I'd
prefer "Taggable" everywhere in this case, sorry:).
23. done everything as described by link, checked how it works/applies on
'origin/0.8.2' from scratch.
24. see 22.2
25. agree, added second constructor with 'String' as clientId, can't remove
constructor with "Taggable" as clientId because as you can see in 22.2
sometimes clientId is not just "clientId" but something more complex.
26. added 'MetricsLeakTest', basic idea is start/stop many producers/consumes
and observe count of metrics in Metrics.defaultRegistry(), count should not
grow.
> Stop using dashes AND underscores as separators in MBean names
> --------------------------------------------------------------
>
> Key: KAFKA-1481
> URL: https://issues.apache.org/jira/browse/KAFKA-1481
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.8.1.1
> Reporter: Otis Gospodnetic
> Priority: Critical
> Labels: patch
> Fix For: 0.8.3
>
> Attachments: KAFKA-1481_2014-06-06_13-06-35.patch,
> KAFKA-1481_2014-10-13_18-23-35.patch, KAFKA-1481_2014-10-14_21-53-35.patch,
> KAFKA-1481_2014-10-15_10-23-35.patch, KAFKA-1481_2014-10-20_23-14-35.patch,
> KAFKA-1481_2014-10-21_09-14-35.patch,
> KAFKA-1481_2014-10-24_14-14-35.patch.patch,
> KAFKA-1481_IDEA_IDE_2014-10-14_21-53-35.patch,
> KAFKA-1481_IDEA_IDE_2014-10-15_10-23-35.patch,
> KAFKA-1481_IDEA_IDE_2014-10-20_20-14-35.patch,
> KAFKA-1481_IDEA_IDE_2014-10-20_23-14-35.patch
>
>
> MBeans should not use dashes or underscores as separators because these
> characters are allowed in hostnames, topics, group and consumer IDs, etc.,
> and these are embedded in MBeans names making it impossible to parse out
> individual bits from MBeans.
> Perhaps a pipe character should be used to avoid the conflict.
> This looks like a major blocker because it means nobody can write Kafka 0.8.x
> monitoring tools unless they are doing it for themselves AND do not use
> dashes AND do not use underscores.
> See: http://search-hadoop.com/m/4TaT4lonIW
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
