[
https://issues.apache.org/jira/browse/SOLR-14683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17226897#comment-17226897
]
Chris M. Hostetter commented on SOLR-14683:
-------------------------------------------
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
