[ 
https://issues.apache.org/jira/browse/KAFKA-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527078#comment-13527078
 ] 

Swapnil Ghike edited comment on KAFKA-646 at 12/8/12 6:17 AM:
--------------------------------------------------------------

Attached patch v2. 

The changes from patch v1:
1. Deleted KafkaHistogram class. (There is also no need for KafkaMeter class.)

2. Deleted the Aggregated*Stats objects. 
- The metrics of SyncProducer and SimpleConsumer for different brokers are 
aggregated together using the same way the producerTopicStats are aggregated 
for "All.Topics". 
- Measuring the time for produce requests and fetch requests is achieved by 
passing a list of timers to KafkaTimer.
                
      was (Author: swapnilghike):
    Attached patch v2. 

The changes from patch v1:
1. Deleted KafkaHistogram class. (There is also no need for KafkaTImer class.)

2. Deleted the Aggregated*Stats objects. 
- The metrics of SyncProducer and SimpleConsumer for different brokers are 
aggregated together using the same way the producerTopicStats are aggregated 
for "All.Topics". 
- Measuring the time for produce requests and fetch requests is achieved by 
passing a list of timers to KafkaTimer.
                  
> 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
>
>
> 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

Reply via email to