Traffic Router (TR) czCount integer overflow in Traffic Ops (TO)

[tcfdev]

This Bug Report affects these Traffic Control components:

• Traffic Ops
• Traffic Router

Current behavior:

Traffic Ops queries the Traffic Router endpoint crs/stats to parse / process / display information. The struct is expecting the czCount field to be a uint64 however in at least one instance the value returned was negative (implying an Integer Overflow in TR).

From the TO error log:

ERROR: api.go:263: <id addr> decoding stats from CDN <CDN name> <traffic router>: json: cannot unmarshal number -2054406724 into Go struct field CRSStatsStat.stats.HTTPMap.czCount of type uint64

Looking into the response from TR, one of the routers reported:

	"server": {
		"czCount": -2055404181, <--- The culprit
		"geoCount": 26857914,
		"deepCzCount": 0,
		"missCount": 1498,
		"dsrCount": 0,
		"errCount": 0,
		"staticRouteCount": 0,
		"fedCount": 0,
		"regionalDeniedCount": 0,
		"regionalAlternateCount": 0
	},

Expected behavior:

The czCount field should certainly not be negative to prevent the bug from happening. However there may a bigger question in terms of "What to do when we've hit the max allowable value of a uint64? Is resetting the values considered appropriate?"

Steps to reproduce:

Whew uhh. Hit an endpoint more than 2 147 483 647 times to see if it rolls over (since Java doesn't have unsigned integer types).

[ocket8888]

Java doesn't have unsigned integer types

That's literally true, but it does provide ways to interpret the data value of a signed integer in unsigned ways. Specifically, the serialization of a count of something should be using the toUnsignedString static method of Java's Integer class. Just an FYI for anyone fixing this.