[
https://issues.apache.org/jira/browse/HDDS-17693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chi-Hsuan Huang updated HDDS-17693:
-----------------------------------
Description:
The heatmap API omits {{color}} when it is 0.0, because
{{EntityReadAccessHeatMapResponse}} uses {{@JsonInclude(NON_DEFAULT)}} on a
primitive {{double}}. {{HeatMapUtil}} floors the color to 3 decimals, so a key
read less than 0.1% as often as the busiest key in its bucket arrives without
{{color}}, for example:
{code}
{"label":"cold-key","path":"/vol1/buck1/cold-key","size":256,"accessCount":1}
{code}
The UI uses {{color}} to detect leaves. {{updateSize}} in {{heatmap.tsx}} only
sets {{normalizedSize}} when the node has {{color}}, so this key gets no size
and is not drawn at all. Giving the same key {{"color": 0.002}} makes it render
normally.
{{nodeClick}} in {{heatmapPlot.tsx}} has the same check ({{!data.color}}), so
once the tile is visible again, clicking it would drill into the key path. Both
checks should tell leaves from groups by structure instead: groups always have
a non-empty {{children}}, and leaves omit it ({{NON_EMPTY}}).
Reproduced with HeatMapUtil.generateHeatMap on two keys in one bucket (5000
reads and 1 read), and by loading that JSON into the Recon UI dev server. Not
yet tried on a live cluster.
was:
The heatmap API omits {{color}} when it is 0.0, because
{{EntityReadAccessHeatMapResponse}} uses {{@JsonInclude\(NON\_DEFAULT\)}} on a
primitive {{double}}. {{HeatMapUtil}} floors the color to 3 decimals, so a key
read less than 0.1% as often as the busiest key in its bucket arrives without
{{color}}, for example:
{code}
{"label":"cold\-key","path":"/vol1/buck1/cold\-key","size":256,"accessCount":1}
{code}
The UI uses {{color}} to detect leaves. {{updateSize}} in {{heatmap.tsx}} only
sets {{normalizedSize}} when the node has {{color}}, so this key gets no size
and is not drawn at all. Giving the same key {{"color": 0.002}} makes it render
normally.
{{nodeClick}} in {{heatmapPlot.tsx}} has the same check \({{\!data.color}}\),
so once the tile is visible again, clicking it would drill into the key path.
Both checks should tell leaves from groups by structure instead: groups always
have a non\-empty {{children}}, and leaves omit it \({{NON\_EMPTY}}\).
Reproduced with HeatMapUtil.generateHeatMap on two keys in one bucket \(5000
reads and 1 read\), and by loading that JSON into the Recon UI dev server. Not
yet tried on a live cluster.
> [Recon][UI] Heatmap hides keys with very low read counts
> --------------------------------------------------------
>
> Key: HDDS-17693
> URL: https://issues.apache.org/jira/browse/HDDS-17693
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: Chi-Hsuan Huang
> Priority: Major
>
> The heatmap API omits {{color}} when it is 0.0, because
> {{EntityReadAccessHeatMapResponse}} uses {{@JsonInclude(NON_DEFAULT)}} on a
> primitive {{double}}. {{HeatMapUtil}} floors the color to 3 decimals, so a
> key read less than 0.1% as often as the busiest key in its bucket arrives
> without {{color}}, for example:
> {code}
> {"label":"cold-key","path":"/vol1/buck1/cold-key","size":256,"accessCount":1}
> {code}
> The UI uses {{color}} to detect leaves. {{updateSize}} in {{heatmap.tsx}}
> only sets {{normalizedSize}} when the node has {{color}}, so this key gets no
> size and is not drawn at all. Giving the same key {{"color": 0.002}} makes it
> render normally.
> {{nodeClick}} in {{heatmapPlot.tsx}} has the same check ({{!data.color}}), so
> once the tile is visible again, clicking it would drill into the key path.
> Both checks should tell leaves from groups by structure instead: groups
> always have a non-empty {{children}}, and leaves omit it ({{NON_EMPTY}}).
> Reproduced with HeatMapUtil.generateHeatMap on two keys in one bucket (5000
> reads and 1 read), and by loading that JSON into the Recon UI dev server. Not
> yet tried on a live cluster.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
