[ 
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

Reply via email to