You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2020/11/05 17:48:00 UTC
[jira] [Comment Edited] (SOLR-14683) Review the metrics API to
ensure consistent placeholders for missing values
[ https://issues.apache.org/jira/browse/SOLR-14683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17226897#comment-17226897 ]
Chris M. Hostetter edited comment on SOLR-14683 at 11/5/20, 5:47 PM:
---------------------------------------------------------------------
Where it's in the spec or not, Solr's JSON Response writer already has long standing support to output {{Float.NaN}} as a quoted string {{"NaN"}}.
If the metrics libraries recommend using NaN as a standard approach to this then i think that makes sense -- anyone consuming Solr's metrics API using the JSON response writer should be able deal with the quoted string -- just like if they found it in any other solr JSON response. (...or switch to using javabin/XML response writer to get a type specific {{NaN}}, or if NaN is really enough of a problem for JSON then we can consdier adding a {{json.nan}} param making the behavior configurable .. but these are all orthoginal to the metrics API doing "the right thing")
was (Author: hossman):
Where it's in the spec or not, Solr's JSON Response writer already has long standing support to output {{Float.NaN}} as a quoted string {{NaN}}.
If the metrics libraries recommend using NaN as a standard approach to this then i think that makes sense -- anyone consuming Solr's metrics API using the JSON response writer should be able deal with the quoted string -- just like if they found it in any other solr JSON response. (...or switch to using javabin/XML response writer to get a type specific {{NaN}}, or if NaN is really enough of a problem for JSON then we can consdier adding a {{json.nan}} param making the behavior configurable .. but these are all orthoginal to the metrics API doing "the right thing")
> Review the metrics API to ensure consistent placeholders for missing values
> ---------------------------------------------------------------------------
>
> Key: SOLR-14683
> URL: https://issues.apache.org/jira/browse/SOLR-14683
> Project: Solr
> Issue Type: Improvement
> Components: metrics
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
>
> Spin-off from SOLR-14657. Some gauges can legitimately be missing or in an unknown state at some points in time, eg. during SolrCore startup or shutdown.
> Currently the API returns placeholders with either impossible values for numeric gauges (such as index size -1) or empty maps / strings for other non-numeric gauges.
> [~hossman] noticed that the values for these placeholders may be misleading, depending on how the user treats them - if the client has no special logic to treat them as "missing values" it may erroneously treat them as valid data. E.g. numeric values of -1 or 0 may severely skew averages and produce misleading peaks / valleys in metrics histories.
> On the other hand returning a literal {{null}} value instead of the expected number may also cause unexpected client issues - although in this case it's clearer that there's actually no data available, so long-term this may be a better strategy than returning impossible values, even if it means that the client should learn to handle {{null}} values appropriately.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org