Cloudera Manager version: Cloudera Enterprise 6.2.0
Swagger api java client: 6.2.0, 6.3.0
In the Swagger client library for Java I've had some situations in which a timeseries request would fail at client side with a NumberFormatException.
Digging I've found that the issue happens when trying to deserialize a "NaN" to a BigDecimal.
This is an example that triggers the issue:
...
"data" : [ {
"timestamp" : "2019-08-14T14:00:00.000Z",
"value" : 2917.75436282436,
"type" : "SAMPLE",
"aggregateStatistics" : {
"sampleTime" : "2019-08-14T13:50:42.000Z",
"sampleValue" : 6882.2668112798265,
"count" : 322211,
"min" : 1566.891751506337,
"minTime" : "2019-08-14T13:36:42.000Z",
"max" : 10739.0,
"maxTime" : "2019-08-14T13:13:42.000Z",
"mean" : 2917.75436282436,
"stdDev" : "NaN"
}
} ]
...
The JSON deserializer tries to bind this message to an ApiTimeSeriesAggregateStatistics which has its metric values fields defined as BigDecimal.
So far I've seen this happening only in the stdDev field.
Having a "NaN" suggests the server side is using Doubles. Is there any reason for the client side to be expecting BigDecimal when it seems the server side is really using Doubles?
As a workaround (not a perfect one) I'm setting a custom instance of GSON to the ApiClient having a custom TypeAdapter for BigDecimal that detects NaN and returns null.
Cloudera Manager version: Cloudera Enterprise 6.2.0
Swagger api java client: 6.2.0, 6.3.0
In the Swagger client library for Java I've had some situations in which a timeseries request would fail at client side with a NumberFormatException.
Digging I've found that the issue happens when trying to deserialize a "NaN" to a BigDecimal.
This is an example that triggers the issue:
The JSON deserializer tries to bind this message to an ApiTimeSeriesAggregateStatistics which has its metric values fields defined as BigDecimal.
So far I've seen this happening only in the stdDev field.
Having a "NaN" suggests the server side is using Doubles. Is there any reason for the client side to be expecting BigDecimal when it seems the server side is really using Doubles?
As a workaround (not a perfect one) I'm setting a custom instance of GSON to the ApiClient having a custom TypeAdapter for BigDecimal that detects NaN and returns null.