sanjeet006py opened a new pull request, #6603: URL: https://github.com/apache/hbase/pull/6603
Summary of the change: - Introduced new class `DelegateTableRunnableWithMetrics` to wrap a runnable and track metrics like execution time and queue wait time. Wrapped existing runnable used by `HTable#batch()` API within `DelegateTableRunnableWithMetrics`. - Introduced class `TableThreadMetricsHolder` to hold metrics for a runnable. There is one-to-one mapping b/w instance of `DelegateTableRunnableWithMetrics` and `TableThreadMetricsHolder`. - Introduced class `TableMetrics` to collect `TableThreadMetricsHolder` objects. There is one TableMetrics object per HTable object. - Exposes list of `TableThreadMetricsHolder` objects by clients so, that clients can aggregate the metrics as per their requirement. Thus, giving them flexibility. But have provided one basic implementation of aggregating metrics from `TableThreadMetricsHolder` objects list. Looking for inputs/suggestions around: - Overall design of the changes. - `TableMetrics` uses synchronized list to store `TableThreadMetricsHolder` objects. Understanding is that its very unlikely that multiple threads are trying to add `TableThreadMetricsHolder` objects to the list simultaneously. But wondering if this can cause batch calls to see increase in latency. - Introduced a config `hbase.client.table.metrics.enable` to skip wrapping runnable inside `DelegateTableRunnableWithMetrics`. Not sure why anyone would want to skip wrapping the runnable given whether to consume metrics is totally upto end user. Maybe we can remove config? Pending: - Adding test coverage. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
