flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chesnay Schepler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-4563) [metrics] scope caching not adjusted for multiple reporters
Date Wed, 28 Sep 2016 14:29:21 GMT

    [ https://issues.apache.org/jira/browse/FLINK-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529812#comment-15529812

Chesnay Schepler commented on FLINK-4563:

I wouldn't store it for different filters for each reporter as it would require a Map<CharacterFilter,
String> to be maintained and accessed on every call to getMetricIdentifier(). I would only
store a version for the first filter that was used; if a second filter is used (which is unlikely
anyway) we will re-create the identifier from scratch. I assume that, if getMetricIdentifier()
was called with different filters, the calls are always made in succession, meaning that with
this scheme we at least cache 50%.

addMetric() and addGroup() should rely on the scopeComponents field for logging purposes,
as it contains the scope in a generalized form.

> [metrics] scope caching not adjusted for multiple reporters
> -----------------------------------------------------------
>                 Key: FLINK-4563
>                 URL: https://issues.apache.org/jira/browse/FLINK-4563
>             Project: Flink
>          Issue Type: Bug
>          Components: Metrics
>    Affects Versions: 1.1.0
>            Reporter: Chesnay Schepler
>            Assignee: Anton Mushin
> Every metric group contains a scope string, representing what entities (job/task/etc.)
a given metric belongs to, which is calculated on demand. 
> Before this string is cached a CharacterFilter is applied to it, which is provided by
the callee, usually a reporter. This was done since different reporters have different requirements
in regards to valid characters. The filtered string is cached so that we don't have to refilter
the string every time.
> This all works fine with a single reporter; with multiple however it is completely broken
as only the first filter is ever applied.

This message was sent by Atlassian JIRA

View raw message