[
https://issues.apache.org/jira/browse/KAFKA-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Ghike updated KAFKA-646:
--------------------------------
Attachment: kafka-646-patch-num1-v5.patch
Patch v5:
40. I agree with you. Created a new trait Config in common package, it has a
method that can validate a clientId or a groupId. ProducerConfig and
ConsumerConfig extend this trait and they have their additional methods to
validate config values that are specific to themselves.
- Moved config value validations in ZookeeperConsumerConnector and Producer to
ConsumerConfig and ProducerConfig objects respectively, since we can throw an
InvalidConfigException when the Config is getting instantiated.
- Moved Topic and TopicTest to common package.
- Added a ConfigTest to common package.
- Removed InvalidClientException and InvalidGroupException. Instead I am now
re-using the existing InvalidConfigException to print the appropriate message.
41. It automatically got changed when I ran sanity test, John probably has a
patch that will add another file run_test, he says we can use it once it is
checked in.
> Provide aggregate stats at the high level Producer and
> ZookeeperConsumerConnector level
> ---------------------------------------------------------------------------------------
>
> Key: KAFKA-646
> URL: https://issues.apache.org/jira/browse/KAFKA-646
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Swapnil Ghike
> Assignee: Swapnil Ghike
> Priority: Blocker
> Labels: bugs
> Fix For: 0.8
>
> Attachments: kafka-646-patch-num1-v1.patch,
> kafka-646-patch-num1-v2.patch, kafka-646-patch-num1-v3.patch,
> kafka-646-patch-num1-v4.patch, kafka-646-patch-num1-v5.patch
>
>
> WIth KAFKA-622, we measure ProducerRequestStats and
> FetchRequestAndResponseStats at the SyncProducer and SimpleConsumer level
> respectively. We could also aggregate them in the high level Producer and
> ZookeeperConsumerConnector level to provide an overall sense of
> request/response rate/size at the client level. Currently, I am not
> completely clear about the math that might be necessary for such aggregation
> or if metrics already provides an API for aggregating stats of the same type.
> We should also address the comments by Jun at KAFKA-622, I am copy pasting
> them here:
> 60. What happens if have 2 instances of Consumers with the same clientid in
> the same jvm? Does one of them fail because it fails to register metrics?
> Ditto for Producers.
> 61. ConsumerTopicStats: What if a topic is named AllTopics? We use to handle
> this by adding a - in topic specific stats.
> 62. ZookeeperConsumerConnector: Do we need to validate groupid?
> 63. ClientId: Does the clientid length need to be different from topic length?
> 64. AbstractFetcherThread: When building a fetch request, do we need to pass
> in brokerInfo as part of the client id? BrokerInfo contains the source broker
> info and the fetch requests are always made to the source broker.
--
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
